Эффективное и масштабируемое хранилище данных JSON с базами данных NoSQL

мы работаем над проектом, который должен собирать данные журнала и аудита и хранить их в хранилище данных для архивных целей и некоторых представлений. Мы не совсем уверены, какое хранилище данных будет работать для нас.

  • нам нужно хранить небольшие документы JSON, около 150 байт, например "audit:{timestamp: '86346512',host':'foo',username:'bar',task:'foo',result:0}" или "journal:{timestamp:'86346512',host':'foo',terminalid:1,type='bar',rc=0}"
  • мы ожидаем около миллиона записей в день, около 150 МБ данных
  • данные будут храниться и считываться, но никогда не изменяться
  • данные должны хранится эффективным образом, например, двоичный формат, используемый Apache Avro
  • после сохранения данные могут быть удалены
  • пользовательские запросы, такие как 'get audit for user and time period' или 'get journal for terminalid and time period'
  • реплицированная база данных для failsafe
  • масштабируемость

В настоящее время мы оцениваем базы данных NoSQL, такие как Hadoop/Hbase, CouchDB, MongoDB и Cassandra. Являются ли эти базы данных подходящим хранилищем данных для нас? Какой из них подойдет лучше всего? Есть ли лучшие варианты?

6
cassandra couchdb hadoop json mongodb

4 ответов

  • один миллион вставок / день около 10 вставок / во-вторых. Большинство баз данных могут справиться с этим, и его намного ниже максимальной скорости вставки, которую мы получаем от Cassandra на разумном оборудовании (50k inserts / sec)

  • ваше требование "после того, как данные времени хранения могут быть удалены" хорошо подходит для столбца TTLs Кассандры - при вставке данных вы можете указать, как долго его хранить, а затем фоновые процессы слияния удалят эти данные, когда он достигнет этого перерыв.

  • "данные должны храниться эффективным образом, например, двоичный формат, используемый Apache Avro" - Cassandra (как и многие другие магазины NOSQL) рассматривает значения как непрозрачные последовательности байтов, поэтому вы можете кодировать значения, как вам нравится. Вы также можете рассмотреть возможность разложения значения на ряд столбцов, что позволит вам выполнять более сложные запросы.

  • пользовательские запросы, такие как "получить аудит для пользователя и периода времени" - в Cassandra вы моделируйте это, имея ключ строки как идентификатор пользователя, а ключ столбца-время события (скорее всего, timeuuid). Затем вы должны использовать вызов get_slice (или даже лучше CQL) для удовлетворения этого запроса

  • или "получить журнал для terminalid и периода времени" - как указано выше, ключ строки будет terminalid, а ключ столбца-timestamp. Следует отметить, что в Cassandra (как и во многих магазинах без соединения), типично вставлять данные более одного раза (в разных аранжировки) оптимизировать для различных запросов.

  • Cassandra имеет очень сложную модель репликации, где вы можете указать различные уровни согласованности для каждой операции. Кассандра тоже очень масштабируемая система без единой точки отказа или ограничения. Это действительно основное различие между Кассандрой и такими вещами, как MongoDB или HBase (не то, что я хочу начать пламя!)

сказав Все это, ваши потребности могут легко удовлетворитесь более традиционной базой данных и простой репликацией master-slave, ничего здесь не слишком обременительно

11

Avro поддерживает эволюцию схемы и хорошо подходит для такого рода проблем.

Если ваша система не требует загрузки данных с низкой задержкой, рассмотрите возможность получения данных в файлы в надежной файловой системе, а не загрузки непосредственно в систему живой базы данных. Поддержание надежной файловой системы (например, HDFS) работает проще и с меньшей вероятностью сбоев, чем живая система баз данных. Кроме того, разделение обязанностей гарантирует, что трафик запросов никогда не повлияет на система сбора данных.

Если у вас будет только несколько запросов для запуска, вы можете оставить файлы в их собственном формате и написать пользовательскую карту для создания необходимых отчетов. Если вам нужен интерфейс более высокого уровня, рассмотрите возможность запуска Hive над собственными файлами данных. Hive позволит вам запускать произвольные дружественные SQL-подобные запросы по вашим необработанным файлам данных. Или, поскольку у вас есть только 150MB / day, вы можете просто пакетно загрузить его в MySQL readonly compressed таблицы.

Если по какой-то причине вам нужна сложность интерактивной системы, HBase или Cassandra или может быть хорошо подходит, но будьте осторожны, что вы потратите значительное количество времени на игру "DBA", а 150MB/day-это так мало данных, что вам, вероятно, не нужна сложность.

4

мы используем Hadoop / HBase, и я посмотрел на Cassandra, и они обычно используют ключ строки в качестве средства для быстрого получения данных, хотя, конечно (по крайней мере, в HBase), вы все равно можете применять фильтры к данным столбцов или делать это на стороне клиента. Например, в HBase вы можете сказать: "Дайте мне все строки, начиная с key1 до, но не включая key2".

поэтому, если вы правильно спроектируете свои ключи, вы можете получить все для 1 пользователя, или 1 хоста, или 1 пользователя на 1 хосте, или вещи как это. Но для этого нужен правильно разработанный ключ. Если большинство ваших запросов должны выполняться с меткой времени, вы можете включить это, например, как часть ключа.

Как часто вам нужно запрашивать данные / записывать данные? Если вы ожидаете запустить свои отчеты, и это нормально, если это займет 10, 15 или более минут (потенциально), но вы делаете много небольших записей, тогда HBase w/Hadoop делает MapReduce (или использует Hive или Pig в качестве языков запросов более высокого уровня) будет работать очень хорошо.

2

если ваши данные JSON имеют переменные поля, то модель без схемы, такая как Cassandra, может очень хорошо удовлетворить ваши потребности. Я бы расширил данные в столбцы, а не хранил их в двоичном формате, что облегчит запрос. С заданной скоростью данных вам потребуется 20 лет, чтобы заполнить диск 1 ТБ, поэтому я бы не беспокоился о сжатии.

в приведенном примере можно создать два семейства столбцов: аудит и журнал. Ключи строк будут TimeUUIDs (т. е. timestamp + MAC-адрес, чтобы превратить их в уникальные ключи). Тогда строка аудита, которую вы дали, будет иметь четыре столбца,host:'foo', username:'bar', task:'foo' и result:0. Другие строки могут иметь разные столбцы.

сканирование диапазона по ключам строк позволит вам эффективно запрашивать в течение периодов времени (при условии, что вы используете ByteOrderedPartitioner). Затем можно использовать вторичные индексы для запроса пользователей и терминалов.

1