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

Question

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

• нам нужно хранить небольшие документы 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'
• реплицированная база данных для отказоустойчивой
• масштабируемая

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Если по какой-то причине вам нужна сложность интерактивной системы, HBase или Cassandra, или она вам подойдет, но учтите, что вы потратите значительное количество времени на игру в «DBA», а 150 МБ / день - это так мало данных что вам, вероятно, не нужна сложность.

Answer 3

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

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

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

Answer 4

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

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

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