магазин уникальных посетителей в распределенной базе данных

Question

у меня есть структура данных, как, что (посетителей веб-сайта)

List(p1,p1,p1,p2,p3,p3,p4,p4,p5...) 

один посетитель может посетить 1 -> много раз объемы

данных: около 100 Milions/день

Как насчет того или иного db я могу хранить уникальных посетителей для быстрого доступа (около реального времени), подобного этому

2014-11-15 | p1 | p2 | p3 | ...| pn 

Я стараюсь обойти с помощью Кассандры с помощью таблицы так:

CREATE TABLE uniqueVisitor (
    key text, 
    p text, 
    PRIMARY KEY (key, data) 
) 

Я думаю, что этот магазин модель не работает очень хорошо, потому что:

Из-за разделение данных этой таблицы , Все данные ключа будут храниться только на одном сервере (с коэффициентом репликации = 1) ==> слишком много запросов на запись могут выбить сервер, который сохранил этот ключ.

Пожалуйста, предложите мне решение (шаблон хранения)

Answer 1

Вы можете использовать набор, так как он устраняет дубликаты (и не имеет никакого определенного упорядочения в ней). Например,

CREATE TABLE uniqueVisitor (
    dt text, 
    users set<text>, 
    PRIMARY KEY (dt) 
); 

Вы правы, данные за один день не распространяются; он будет на одном узле (и репликах). Разумеется, раздельные записи разных дат будут распределены. Так что это потенциальная точка доступа. Сказав это, я думаю, что горячая точка записи может не иметь большого значения в этом случае, так как это единственная (хотя и гигантская) запись, которая изменяется. Каждый пользовательский визит не приведет к дисковым ввода-выводам, поскольку изменения сначала будут сделаны в памяти, в memtables, и только когда memtables будет сброшен на диск, он будет записан в SSTable. Данные из нескольких SSTables будут периодически уплотняться, что может иметь определенную производительность, хотя я полагаю, что это не приведет к укушению вашего приложения.

В Cassandra 2.1 также можно создавать индексы для типов коллекций, таких как SET.

Надеюсь, это поможет.

Answer 2

Это довольно распространенное явление при работе с потоками данных большого объема, чтобы пожертвовать некоторой точностью для повышения эффективности. Существуют некоторые алгоритмы для оценки числа уникальных данных, данных в потоке данных большого объема. Они требуют гораздо меньше места, чем простое хранение каждого уникального, требуют гораздо меньшей обработки (могут выполняться в памяти на одном узле даже - или нескольких узлов) и дают результаты с точностью не менее 50% (и намного больше, если вы делать больше работы). Посмотрите алгоритм Flajolet-Martin и (лучше) алгоритм Alon-Matias-Szegedy (AMS). Здесь вы можете найти краткие описания: http://www.st.ewi.tudelft.nl/~hauff/BDP-Lectures/3_streams.pdf и подробный анализ в Prof. Ullman et. al., которая свободно доступна здесь: http://mmds.org/. Я считаю, что в главе 4 рассказывается о потоковой обработке.