|
Cassandra, проектирование БД
|
|||
---|---|---|---|
#18+
Коллеги, вопрос к специалистам по Cassandra. Дано: есть события (сотни миллионов), которые генерируются неким сторонним СПО. Есть набор типов событий, 2-3 миллионов, которые медленно пополняются. Необходимо построить схему БД для хранения и поиска событий по типам за определённый период. Как я правильно понял дао кассандры, то мы создаём column families, например, EVENTS для хранения самих событий. Дальше нам нужно создать, так называемый "index", что в кассандре, является, тем же CF. Создаём CF EV_TYPE_TIMELINE, где rowkey — это тип события, column_name — это время события, value — ссылка на таблицу events: CF EV_TYPE_TIMELINE {type_events, {datetime:<rowkey_events>}}. Но проблема возникла, в том, что несколько событий с одним и тем же типом, но разным набором данным могут быть получены за один момент времени. Таким образом column_name в CF EV_TYPE_TIMELINE получается не уникальным и сохраняться будет только одно значение. Какие архитектурные пути решения существуют в кассандре для решения задачи не уникального индекса? То что приходит в голову: 1. В column_name CF EV_TYPE_TIMELINE записывать не только дату события, но и timestamp времени обработки события. Таким образом мы обеспечим уникальность имени столбца, но возрастает объём хранения информации. Также увеличивается время работы запросов на получения данных по range columns. 2. События приходят пачками, если упростить, то раз в 10 минут. События могут приходить за предыдущие время. На каждую пачку, мы создаём свой EV_TYPE_TIMELINE_1, таким образом в БД хранится большое количество column families, по которым мы осуществляем поиск. Насколько такой подход соответствует ДАО кассандры: ~миллион СF в одной БД. 3. Другие подходы? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2012, 11:17 |
|
|
start [/forum/topic.php?fid=48&fpage=12&tid=1856975]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
14ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 144ms |
0 / 0 |