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

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

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

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

объемы данных: около 100 млн/день

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

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

Я пытаюсь обойти это, используя Cassandra, используя такую ​​​​таблицу:

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

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

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

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


database cassandra bigdata real-time-data
person tnk_peka    schedule 01.12.2014    source источник
comment
Я хотел бы помочь вам, но я не уверен, что правильно понял ваш вопрос. В таблице uniqueVisitor что вы хотите сохранить в ключевом поле: дату, ссылку на веб-страницу или что-то еще? Аналогично, что такое p: это имя посетителя или что-то еще?   -  person Pradyumn    schedule 01.12.2014
comment
спс за вашу помощь! мне нужно хранить только userId!! Ключ представляет собой простую строку даты: пример «2014-12-01»   -  person tnk_peka    schedule 01.12.2014

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Pradyumn    schedule 02.12.2014
comment
ткс прадьюмн! Я рассмотрю возможность использования Set в своей таблице! - person tnk_peka; 02.12.2014
comment
Будьте осторожны с ограничением размера коллекций в 64 КБ. - person ashic; 02.12.2014

arrow_upward
1
arrow_downward

Довольно часто при работе с потоками данных большого объема приходится жертвовать некоторой точностью ради эффективности. Есть несколько алгоритмов для оценки количества уникальных данных при большом объеме потока данных. Они требуют намного меньше места, чем простое хранение каждого уникального файла, требуют гораздо меньше обработки (может выполняться в памяти даже на одном узле — или нескольких узлах) и обеспечивают результаты с точностью не менее 50% (и намного больше, если вы делать больше работы). Взгляните на алгоритм Флажоле-Мартина и (лучше) алгоритм Алона-Матиаса-Сегеди (AMS). Краткое описание можно найти здесь: http://www.st.ewi.tudelft.nl/~hauff/BDP-Lectures/3_streams.pdf и подробный анализ в Prof. Ullman et. al., которая находится в свободном доступе здесь: http://mmds.org/. Я считаю, что это глава 4, которая довольно хорошо описывает потоковую обработку.

person ashic    schedule 02.12.2014