|
|
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Добрый день, господа программисты. Представьте себе, что есть модуль, на вход которому бесконечно поступают ID пользователей. В любой момент времени м одуль должен уметь быстро ответить сколько за всё время накопилось уникальных пользователей . Каким образом Вы бы стали решать задачу при условии, что: 1) нужно получить точное количество уникальных пользователей 2) достаточно примерного значения с погрешностью, не превышающей нескольких процентов -- Мое видение: Главное и ключевое слово "бесконечно". Это означает, что мы не можем хранить все записи. Если бы мы могли хранить все записи, то для первого пункта можно было бы создать Map из уникальных ID и потом брать его "длину". Но опять же это неправильно, если рассматривать бесконечный поток данных. Ваши идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 14:50 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Межгалактическую систему идентификации планируете? ВикиНаселение земли 1 ноября 2011 — 7,0 млрд человек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:01 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Зачем мап? Возьми полноценный SQL-сервер и пиши туда все входящие ID и время поступления. Получишь таблицу с логом, а дальше хоть какие выборки делай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:05 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Для бесконечного потока не поможет, жесткие диски конечны. Другое дело, если на магнитной ленте - тогда подклеивать можно, скотчем. Главное, что бы атомы железа для феромагнитного покрытия во вселенной раньше не закончились. Как я понимаю, атомов железа не так уж и много, с точки зрения бесконечности... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:08 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
хорошо троллите, но нужна помощь Считайте, что у меня сервер на Пентиум4 с жестким диском на 128Мб. И забудьте про БД, в данной задаче речь идет о Структурах Данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:21 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Пофиг какой у тебя сервер. Планируемые характеристики задачи надо конкретнее задавать. Какой тип и размер у ID? На какое число уникальных пользователей примерно рассчитывать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:25 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
ID : String Количество: население Земли х10 (по 10 аккаунтов). Чтобы отпало желание хранить их всех в БД и проверять на наличие повторения (уникальность). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:31 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
у тебя уже отпало? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:32 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, Я разрешаю вам больше не писать в данном топике. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:36 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
если нет возможности хранить map уникальных id (их слишком много), то никак. вот поступает на вход новое id - как проверить, что оно уже было? но сдается мне, 70 миллиардов строк хранить таки можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:42 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
В целом задача сводится к тому что надо проверить было ли такое значение ID, это не реализовать без хранения факта что оно было. Т.е. минимум места 1 бит на один ID. Или 8 ID в одном байте. Это идеал, в реале будут издержки на организацию хранения, думаю можно вписаться в 2-4 ID на один байт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:48 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Dima TТ.е. минимум места 1 бит на один IDтам id - строки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 15:50 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Яростный МечDima TТ.е. минимум места 1 бит на один IDтам id - строки можно к числам свести, например посчитать CRC37, что сделает из строки 37-битное число с заданной погрешностью 1-2% Если изначально на такой размер рассчитывать и не заморачиваться что возможно их намного меньше, то надо кусок памяти 2^29 байт = 0,5 Гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 16:07 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Меня другое интересует, как эти 70 млрд. ID на сервер попадут? Допустим средний логин 15 байт, т.е. это 1 Тб трафика только на передачу логинов, а ведь еще и полезная инфа будет и ответ ... для обработки всего этого безобразия датацентр потребуется построить, так что жалкие 0,5 Гб памяти для подсчета там найдутся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 16:34 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Занизил я 0,5 Гб, надо 16 Гб (2^34). Не суть, если гигантоманией не страдать и поставить нормальный предел в 8 млн. уникальных ID, то хватит массива в 1 Мб: Считаешь CRC32 от ID (совпадать будет с погрешностью несколько %), оставляешь 23 бита: 20 номер элемента массива, 3 номер бита. Метишь бит в 1. Для вывода результата считаешь биты установленные в 1. Вместо CRC32 можно любой другой хэш взять (MD5 например), просто затестить какой быстрее считается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 16:50 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
eldarkaaхорошо троллите, но нужна помощь Считайте, что у меня сервер на Пентиум4 с жестким диском на 128Мб . И забудьте про БД, в данной задаче речь идет о Структурах Данных. На какой барахолке Вы такой достанете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 18:55 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
BagaBagaНа какой барахолке Вы такой достанете?Ни на какой. Не было таких дисков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 19:07 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovBagaBagaНа какой барахолке Вы такой достанете?Ни на какой. Не было таких дисков. Было и даже меньше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 19:36 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Dima T Было и даже меньше Было 120Мб. 128 - не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 04:29 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
eldarkaaМое видение: Главное и ключевое слово "бесконечно". Это означает, что мы не можем хранить все записи. Твоё видение в корне неверно. Потому что если брать это ограничение за основу, то решений у задачи нет. Бесконечного ничего не бывает в жизни. Есть только недалёкие постановщики задачи, которым лень думать о сроках этой "конечности". Значит, надо ввести ограничения, какие-то очень большие, но всё же конечные. Ну и очевидно, что задача вычисления уникального множества без наличия какой-то памяти, где можно было бы это хранить, не решается. Именно MAP из уникальных ID, и его длина. MAP либо в памяти, либо на диске (и частично в памяти). Либо распределённый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:18 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
eldarkaaхорошо троллите, но нужна помощь Считайте, что у меня сервер на Пентиум4 с жестким диском на 128Мб. И забудьте про БД, в данной задаче речь идет о Структурах Данных. БД -- это одна из структур данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:19 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
eldarkaaID : String Количество: население Земли х10 (по 10 аккаунтов). Чтобы отпало желание хранить их всех в БД и проверять на наличие повторения (уникальность). Ну, я имел дело с БД такого размера (55 миллиардов записей). Вполне успешно работала на кластере из 8 машин. 32 гига памяти кажется в каждой, по 16 процов (кажется). Но это не бесконечность. Кстати, в ходе этого проекта я понял, насколько трудно найти сейчас реально большие данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:22 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
MasterZiveldarkaaID : String Количество: население Земли х10 (по 10 аккаунтов). Чтобы отпало желание хранить их всех в БД и проверять на наличие повторения (уникальность). Ну, я имел дело с БД такого размера (55 миллиардов записей). Вполне успешно работала на кластере из 8 машин. 32 гига памяти кажется в каждой, по 16 процов (кажется). Но это не бесконечность. Кстати, в ходе этого проекта я понял, насколько трудно найти сейчас реально большие данные. Да, в этой БД хранилось немного больше, чем просто ID для каждого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:23 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
MasterZivMasterZivпропущено... Ну, я имел дело с БД такого размера (55 миллиардов записей). Вполне успешно работала на кластере из 8 машин. 32 гига памяти кажется в каждой, по 16 процов (кажется). Но это не бесконечность. Кстати, в ходе этого проекта я понял, насколько трудно найти сейчас реально большие данные. Да, в этой БД хранилось немного больше, чем просто ID для каждого. И запросы были много сложнее, чем поиск по ID. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:24 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Яростный Мечесли нет возможности хранить map уникальных id (их слишком много), то никак. вот поступает на вход новое id - как проверить, что оно уже было? но сдается мне, 70 миллиардов строк хранить таки можно. 70 не знаю, а вот 60 (~кол-во пальцев на руках у всех жителей земли) -- вполне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:25 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Dima TВместо CRC32 можно любой другой хэш взять (MD5 например), просто затестить какой быстрее считается.Ну глядя на алгоритмы, md5 должен быть примерно в 30 раз медленнее crc. Ну так то да, если допустима погрешность, то взять какой-нибудь хеш и хранить по биту на каждое его возможное значение - самый компактный способ хранения будет. Только размер хеша надо правильно выбрать. А то для crc32 больше четырех с небольшим миллиардов уникальных пользователей никак не получится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 12:38 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Главное, не забывайте про зеленных человечков с Марса!!! Они тоже хотят, что бы их посчитали. CRC32 и придел в 4 млр. не катит Да... и не забывайте требования к оборудованию... нужно все на 128 Mb диске сделать.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 15:44 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Можно CRC64 взять и чтобы в 128 уложиться жать JPEG`ом раз небольшие потери разрешены ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 15:52 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Ребята, какие такие хэши, все хэши теряют данные, уникальность после хэша не проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 16:08 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
MasterZiv, ознакомься с ТЗ eldarkaa2) достаточно примерного значения с погрешностью, не превышающей нескольких процентов Осталось провести исследование сколько процентов теряют разные хэши, чтобы уложиться в заданные пределы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 16:16 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Я как-то такое исследование устраивал, надо было ускорить поиск по точному совпадению строки char(100) в таблице из полумиллиона уникальных записей. Оказалось CRC32 почти тянет на уникальный ключ, повторов было очень мало. Но если всегда считать CRC от 100 символов, а если обрезать конечные пробелы - количество повторов значительно увеличиваются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 16:26 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Dima TMasterZiv, ознакомься с ТЗ eldarkaa2) достаточно примерного значения с погрешностью, не превышающей нескольких процентов Осталось провести исследование сколько процентов теряют разные хэши, чтобы уложиться в заданные пределы.Дело не в том, сколько теряют хэши, а в том, каково распределение входных данных. Если, например, функия хэша дает одинаковое значение (т.е. коллизию) для четного N и для нечетного N+1, а во входном потоке четных чисел на порядок больше, чем нечетных, то погрешность составит десятки-сотни процентов, а вовсе не 1/N. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 16:33 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Фильтр Блума частично решает проблему существования ключа в бесконечной выборке при условии конечной памяти самого фильтра. Но подсчёт (итератор) в нем невозможен. Кроме того из постановки вопроса непонятно, были ли транзакции на удаление ключей. Если нет - в большинстве случаев можно просто анализировать count(*) событий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 19:01 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
eldarkaa, Вам нужно просто осознать, что ничего бесконечного не бывает. Потом оценить разумно объем данных которые РЕАЛЬНО нужно хранить. Уверен, что ничего суперсложного в вашей задаче не останется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2014, 01:43 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Эту задачу решает вот такая штука: http://ru.wikipedia.org/wiki/Фильтр_Блума Только вам нужен Multiset, т.е. вместо битового массива нужен массив счетчиков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2014, 08:25 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
MasterZivТвоё видение в корне неверно. Потому что если брать это ограничение за основу, то решений у задачи нет. Правильный ответ уже был. И на пункт а, и на пункт б. Ваша задача(оба пункта) практически равносильна попытке найти сумму расходящегося ряда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2014, 03:16 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Dima TMasterZiv, ознакомься с ТЗ eldarkaa2) достаточно примерного значения с погрешностью, не превышающей нескольких процентов Осталось провести исследование сколько процентов теряют разные хэши, чтобы уложиться в заданные пределы. Ну-ну, успехов .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2014, 14:09 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
MasterZivНу-ну, успехов .... Успехи есть, выше писал, работает в реальном проекте. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2014, 14:16 |
|
||
|
Алгоритмы для бесконечного потока данных.
|
|||
|---|---|---|---|
|
#18+
Глянул текущее состояние: почти 495 тыс. уникальных записей, совпавших CRC32 - всего 29 штук Если взять остаток деления CRC32 на 1 Мб - дублей 100 тыс. 2 мб - 54 тыс. 4 мб - 28 тыс. 8 мб - 14 тыс. 16 мб - 7 тыс. Зависимость точности от объема просматривается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2014, 14:44 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1341222]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
7ms |
get forum data: |
1ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 315ms |

| 0 / 0 |
