В какой базе данных можно было бы хранить миллиарды /триллионы записей?

Мы рассматриваем разработку инструмента для сбора и анализа данных Netflow, из которых мы собираем огромные суммы. Каждый день мы записываем около 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 выглядит многообещающим, но представляется гораздо более сложным для масштабирования, поскольку он является ведущим /подчиненным /осколком. Некоторые другие кандидаты, которые мы планируем оценить, это elasticsearch, mysql (не уверен, что это применимо) и несколько реляционных баз данных, ориентированных на столбцы. Любые предложения или реальный опыт в мире будут оценены.

72 голоса | спросил somecallmemike 28 MarpmThu, 28 Mar 2013 20:23:23 +04002013-03-28T20:23:23+04:0008 2013, 20:23:23

5 ответов


55

В компании, в которой я работаю, мы имеем дело с подобным объемом данных (около 10 Тбайт данных в реальном времени для поиска). Мы решаем это с Cassandra, и я хотел бы упомянуть пару идей, которые позволят вам выполнять поиск O (1) в базе данных с несколькими ТБ. Это не относится к Cassandra db, хотя вы можете использовать его и с другими db.

Теория

  • Опечатать ваши данные. Нет никакого способа, чтобы один сервер мог надежно и реалистично хранить такой объем данных.
  • Будьте готовы к сбоям оборудования и сбоям всего узла, дублируйте данные.
  • Начало использования многих серверных серверов с самого начала.
  • Используйте много более дешевых товарных серверов, по сравнению с высокопроизводительными высокопроизводительными.
  • Убедитесь, что данные распределены равномерно по осколкам.
  • Проведите много времени, планируя свои запросы. Выводите API из запросов, а затем тщательно разрабатывайте таблицы. Это самая важная и продолжительная задача.
  • В Cassandra вы можете создать составной столбчатый ключ и получить доступ к этому ключу в O (1). Потратьте время на них. Это будет использоваться для доступа к поисковым записям вместо вторичного индекса.
  • Используйте широкие ряды. Они полезны для хранения событий с отметкой времени.
  • Никогда не выполняйте полное сканирование или фактически любую операцию больше, чем O (Log N) на этом томе. Если вам требуется что-то большее, чем O (Log N), разгрузите такие операции в алгоритмы Map-Reduce.

Практика

  • Не тратьте время на создание изображений ОС или установку серверов на физических машинах. Используйте облачные провайдеры для быстрого прототипирования. Я работал с Amazon EC2 и могу очень рекомендовать его для его простоты, надежности и скорости прототипирования.
  • Машины Windows работают медленнее во время загрузки и потребляют значительно больше ресурсов, находящихся в состоянии ожидания. Рассмотрим использование ОС на базе Unix. Лично я нашел сервер Ubuntu надежной ОС, но, кроме того, в askubuntu] существует довольно хорошее сообщество
  • Подумайте о сети, узлы в идеале должны быть близки друг к другу, чтобы обеспечить быстрое сплетение и обмен метаданных.
  • Не вдаваться в крайние случаи: действительно широкие строки столбцов или исключительно длинные семейства столбцов (таблицы). Наилучшая производительность достигается в разумных границах - если db поддерживает множество строк N по дизайну, это не значит, что он работает хорошо.
  • Наш поиск занимает около 3-5 секунд, многое из-за промежуточных узлов между UI и базой данных. Подумайте, как приблизить запросы к базе данных.
  • Использовать балансировщик сетевой нагрузки. Выберите установленный. Мы используем HAProxy, который прост, но мертв быстро. Никогда не было проблем с этим.
  • Предпочитают простоту для сложных решений.
  • Ищите бесплатные решения с открытым исходным кодом, если только вы не подкреплены бюджетом размера корпорации. После того, как вы перейдете к нескольким серверам, стоимость инфраструктуры может быть высокой.

Я не работаю для Amazon и не имею никаких отношений с командами HAProxy и Ubuntu. Это личное мнение, а не какое-либо продвижение.

ответил oleksii 29 MaramFri, 29 Mar 2013 00:31:39 +04002013-03-29T00:31:39+04:0012 2013, 00:31:39
40

Если бы я собирался поместить это в SQL Server, я бы предложил таблицу что-то вроде:

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

Это приводит к суммарному ожидаемому требованию к хранению для отдельной таблицы без каких-либо дополнительных индексов 5.5 ТБ для 43.2 записей биений (ваше указанное требование). Это вычисляется как 130 байт для самих данных плюс 7 байт на строку служебных данных плюс 96 байт на страницу служебных данных. SQL Server хранит данные на страницах размером 8 КБ, что позволяет использовать 59 строк на странице. Это равно 732 203 390 страниц за один месяц данных.

SQL Server любит писать на диск в 8-страничных фрагментах (64 КБ), что соответствует 472 строкам на каждый физический ввод-вывод. Когда каждую секунду генерируют 16203 потока записей, вам потребуется минимальная скорость ввода-вывода в 34 IOps, гарантированная каждую секунду. Хотя это само по себе не является огромной суммой, другие операции ввода /вывода в системе (SQL Server и др.) Не должны нарушать эту необходимую скорость IOps. Поэтому вам нужно разработать систему, способную, по крайней мере, на порядок больше IOps или 340 устойчивых IOps - я бы оценил, что вам нужно 2-го порядка более устойчивых IOps, чтобы гарантировать пропускную способность.

Вы заметите, что я не хранил IP-адреса в их десятичной форме. Это экономит огромную сумму на хранении (7 байт на адрес), а также делает индексацию, поиск, сортировку и сравнение IP-адресов намного эффективнее. Недостатком здесь является то, что вам нужно преобразовать десятичные десятичные десятичные числа в 8-байтовые целые числа перед их сохранением и вернуться к десятичным десятичным IP-адресам для отображения. Код для этого тривиально, однако ваша скорость строки добавит значительную часть накладных расходов на обработку каждой обрабатываемой строки потока - вы можете захотеть сделать этот процесс преобразования на физически другой машине с SQL Server.

Обсуждение требуемых индексов - это совершенно отдельный вопрос, поскольку вы не указали никаких конкретных требований. Конструкция этой таблицы будет хранить строки потока в физическом порядке, который они получают SQL Server, поле tcp_traffic_id уникально для каждой записи и позволяет сортировать строки по порядку их записи (в этом случае скорее всего, связанный один-к-одному со временем события потока).

ответил Max Vernon 28 MarpmThu, 28 Mar 2013 22:30:16 +04002013-03-28T22:30:16+04:0010 2013, 22:30:16
5

Я бы рекомендовал HBase . Вы можете хранить все необработанные данные в одной или нескольких таблицах HBase, в зависимости от того, что вам нужно запросить. HBase может обрабатывать большие наборы данных и выполняет автоматическое разбиение по регионам.

Кроме того, если вы хорошо проектируете строки, вы можете получить чрезвычайно быстрые, даже O (1) запросы. Обратите внимание: если вы извлекаете большой набор данных, это все равно будет медленным, так как извлечение данных - это операция O (n).

Поскольку вы хотите запросить через каждое поле, я бы рекомендовал создать уникальную таблицу для каждого из них. Пример для данных src_address, имеет таблицу, которая выглядит так:

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

Итак, если вы хотите запросить все данные в 1.2.3.4, начиная с 27 марта с 12:00 до 27 марта 12:01, вы можете выполнить сканирование диапазона с указанными начальными и конечными строками.

IMHO, дизайн ключевых строк является наиболее важной частью использования HBase - если вы хорошо его разрабатываете, вы сможете выполнять быстрые запросы и хранить большие объемы данных.

ответил Suman 29 MaramFri, 29 Mar 2013 02:36:35 +04002013-03-29T02:36:35+04:0002 2013, 02:36:35
3

Сказал:

  

... мы не против смотреть на собственные решения для этого   Проект

Я предлагаю рассмотреть базу данных IBM Informix + TimeSeries datablade. Напротив того, что говорят некоторые люди, Informix жив и идет очень хорошо. Последняя версия была выпущена в прошлом месяце (март /2013, версия 12.10).

TimeSeries похож на «плагин» (без затрат), способный справляться с такими ситуациями, как ваш.
И вы можете использовать его в производстве со свободной версией базы данных Informix ( издание Innovator-C ). (конечно, только для оценки технических деталей, так как у бесплатной версии есть много ограниченных ресурсов)

Здесь вы можете проверить PDF-ориентир , что может в качестве ссылки. Здесь две презентации с более техническими примерами: руководство для манекенов и другие советы

У меня нет личного опыта работы с TimeSeries , поэтому я не могу согласиться, что это будет «решение», просто предложение оценить.

ответил ceinmart 6 AMpSat, 06 Apr 2013 07:13:30 +040013Saturday 2013, 07:13:30
2

Во-вторых, рекомендуем взглянуть на Informix TimeSeries. IBM утверждает, что TimeSeries может хранить этот вид информации в 1/5-м пространстве и выполнять в 5 раз быстрее, чем традиционные реляционные таблицы.

Дополнительными преимуществами будет интерфейс виртуальных таблиц, который может заставить данные TimeSeries выглядеть как традиционные реляционные таблицы для конечного пользователя (упрощая разработку приложений, сохраняя при этом все преимущества TimeSeries), простой HA с узлами HDR, которые теперь поддерживают данные TimeSeries в версии 12.1 и интеграции данных TimeSeries в Informix Warehouse Accelerator, которые могут быть использованы для ускорения сложных отчетов хранилища данных и возможности прототипа решения TimeSeries в Informix с использованием бесплатных выпусков Informix Developer или Innovator-C.

ответил Andrew 6 PMpSat, 06 Apr 2013 16:56:29 +040056Saturday 2013, 16:56:29

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132