Фильтрация повторяющихся ключей

Question

Я ищу распределенное решение для фильтрации/фильтрации большого объема ключей в режиме реального времени. Мое приложение генерирует более 100 миллиардов записей в день, и мне нужен способ фильтрации дубликатов из потока. Я ищу систему для хранения скользящих 10-дневных ключей, примерно 100 байт на ключ. Мне было интересно, как этот тип крупномасштабной проблемы был решен до использования Hadoop. Будет ли HBase правильным решением для использования? Кто-нибудь когда-либо пробовал частично встроенное решение, такое как Zookeeper?

Answer 1

Я вижу ряд решений вашей проблемы, но требования в реальном времени действительно сужают его. В реальном времени вы имеете в виду, что хотите увидеть, является ли ключ дубликатом, поскольку он создается?

Давайте поговорим о запросах в секунду. Вы говорите 100B/день (это много, поздравляю!). Это 1,15 миллиона запросов в секунду (100 000 000 000/24/60/60). Я не уверен, сможет ли HBase справиться с этим. Возможно, вам захочется подумать о чем-то вроде Redis (возможно, ошпаренном) или Membase/memcached или что-то в этом роде.

Если бы вы сделали это в HBase, я бы просто нажал на триллионы ключей (10 дней x 100B ключей) в качестве ключей в таблице и поставил для этого некоторое значение, чтобы сохранить его (потому что вы должен). Тогда вы можете просто понять, есть ли ключ. Это своего рода hokey и не полностью использует hbase, поскольку он полностью использует пространство ключей. Таким образом, эффективно HBase - это b-tree-сервис в этом случае. Я не думаю, что это хорошая идея.

Если вы расслабляете сдержанность, чтобы не работать в режиме реального времени, вы можете использовать MapReduce в пакетном режиме для дедуплирования. Это довольно просто: это просто количество слов без учета. Вы группируете ключ, который у вас есть, а затем вы увидите дубликатов в редукторе, если вернутся несколько значений. С достаточным количеством узлов достаточно латентности, вы можете эффективно решить эту проблему. Вот пример кода для этого из книги MapReduce Design Patterns: https://github.com/adamjshook/mapreducepatterns/blob/master/MRDP/src/main/java/mrdp/ch3/DistinctUserDriver.java

ZooKeeper предназначен для передачи и синхронизации распределенных процессов. Вы не хотите хранить триллионы записей в zookeeper.

Итак, в моем мнениях, вам лучше обслуживать хранилище ключей/значений в памяти, такое как redis, но вам будет трудно сохранить такое количество данных в памяти.

Answer 2

Я боюсь, что это невозможно с помощью традиционных систем: |

Вот что U упомянул:

1. 100 миллиардов долларов дней означает Аппроксимация 1 миллион в секунду !!!!
2. Размер ключа составляет 100 байт.
3. U хотите проверить наличие дубликатов в 10-дневном рабочем наборе - 1 триллион предметов.

Эти предположения приводят к поиску в наборе из 1 триллиона объектов, которые полностью размерны в 90 TERABYTES !!!!! Любое решение этой проблемы в реальном времени должно обеспечить систему, которая может искать 1 миллион элементов в секунду в этом объеме данных. У меня есть опыт работы с HBase, Cassandra, Redis и Memcached. Я уверен, что U не может достичь этой производительности на любом дискового хранилища, такого как HBase, Cassandra или HyperTable (и добавлять к ним любые RDBMS, такие как MySQL, PostgreSQl и ...). Наилучшая производительность redis и memcached, которые я слышал, составляет около 100 тыс. Операций в секунду на одной машине. Это означает, что U должен иметь 90 машин, каждый из которых имеет 1 TERABYTES ОЗУ !!!!!!!!
Даже система пакетной обработки, такая как Hadoop, не может выполнить эту работу менее чем за час, и я думаю, что это займет часы и дни даже на большом кластере из 100 машин.

U R, говорящий о очень очень больших количествах (90 ТБ, 1 М в секунду). R U уверенный об этом ???