Мы смотрим на разработку инструмента для сбора и анализа данных сетевых потоков, из которых мы собираем огромное количество. Каждый день мы собираем около 1,4 миллиарда записей о потоках, которые выглядят так в формате json
{
"tcp_flags": "0",
"src_as": "54321",
"nexthop": "1.2.3.4",
"unix_secs": "1352234521",
"src_mask": "23",
"tos": "0",
"prot": "6",
"input": "105",
"doctets": "186",
"engine_type": "0",
"exaddr": "2.3.4.5",
"engine_id": "2",
"srcaddr": "9.8.7.6",
"dst_as": "12345",
"unix_nsecs": "752265174",
"sysuptime": "2943529544",
"dst_mask": "24",
"dstport": "80",
"last": "2943523241",
"srcport": "52672",
"dpkts": "4",
"output": "111",
"dstaddr": "6.5.4.3",
"first": "2943517993"
}
Мы хотели бы иметь возможность выполнять быстрый поиск (менее 10 секунд) по набору данных, скорее всего, по узким отрезкам времени (интервалы 10–30 минут). Мы также хотим индексировать большинство точек данных, чтобы мы могли быстро выполнять поиск по каждой из них. Мы также хотели бы иметь актуальное представление данных при выполнении поиска. Было бы здорово остаться в мире открытого исходного кода, но мы не против того, чтобы искать собственные решения для этого проекта.
Идея состоит в том, чтобы хранить примерно один месяц данных, что составляет ~ 43,2 миллиарда записей. По приблизительным оценкам, каждая запись будет содержать около 480 байт данных, что будет равно ~ 18,7 терабайт данных в месяц, а может быть и в три раза больше, чем с индексами. В конечном итоге мы хотели бы расширить возможности этой системы для хранения триллионов записей.
Мы (в основном) оценили couchbase, cassandra и mongodb в качестве возможных кандидатов для этого проекта, однако каждый из них предлагает свои собственные задачи. С помощью couchbase индексация выполняется с интервалами, а не во время вставки данных, поэтому представления не обновляются, вторичные индексы cassandra не очень эффективны при возвращении результатов, так как обычно для них требуется сканирование всего кластера, а mongodb выглядит многообещающе, но кажется, что его гораздо сложнее масштабировать, поскольку он является главным / подчиненным / осколочным. Некоторые другие кандидаты, которые мы планируем оценивать, являются эластичный поиск, MySQL (не уверен, если это даже применимо), и несколько ориентированных на столбцы реляционных баз данных. Любые предложения или опыт реального мира будут оценены.