Как эффективно хранить и запрашивать миллиард строк данных датчиков
Ситуация: я начал новую работу и получил задачу выяснить, что делать с их таблицей данных датчика. Он имеет 1,3 миллиарда строк данных датчиков. Данные довольно просты: в основном это просто идентификатор датчика, дата и значение датчика в тот момент времени (в два раза).
В настоящее время данные хранятся в таблице в базе данных MSSQL Server.
Я ожидаю, что к концу этого года количество строк увеличится до 2-3 миллиардов.
Я ищу лучший способ хранить и запрашивать эти данные (по дате), и поскольку у нас есть много продуктов с "большими данными", и у меня нет реального опыта управления такими большими наборами данных, я спрашиваю здесь для любых указателей.
Это небольшая компания, и наши ресурсы не безграничны;)
Еще несколько подробностей о нашем случае использования:
- Данные представлены в виде графиков и показывают значения датчиков во времени.
- Мы планируем создать API, чтобы наши клиенты могли получать данные датчиков за любой интересующий их период времени (... данные за 2 года назад так же актуальны, как и данные за последний месяц).
Мои исследования привели меня к рассмотрению следующих решений:
Храните данные в SQL Server
но разбить таблицу (сейчас она не разбита). Это потребует корпоративной версии SQL Server, которая стоит много.
Переместите данные на Azure SQL Server.
Там мы получим функцию разделения за гораздо меньшие деньги, но как только наша БД вырастет до 250 ГБ, она будет стоить намного дороже (и слишком сильно превысит 500 ГБ).
Используйте несколько баз данных
Мы могли бы использовать 1 БД на клиента. Несколько небольших БД будут дешевле, чем 1 огромная БД, но у нас много клиентов и планы на большее, поэтому мне не очень нравится думать об управлении всеми этими базами данных.
Таблицы хранилища Azure
Этот вариант мне больше всего нравится. Мы можем разделить данные по компании / датчику / году / месяцу, использовать дату для ключа строки и сохранить значение датчика.
У меня еще не было времени проверить производительность запросов, но из того, что я прочитал, должно быть хорошо. Но есть один существенный недостаток, и это ограничение 1000 элементов, возвращаемых за HTTP-запрос. Если нам нужно получить все данные датчика за неделю, нам нужно сделать много HTTP-запросов. Сейчас я не уверен, насколько серьезна проблема для нашего варианта использования.
Azure HDInsight (Hadoop в Azure)
Как уже упоминалось, у меня нет опыта работы с большими данными, и в настоящее время я недостаточно хорошо разбираюсь в Hadoop, чтобы знать, подходит ли он для нашего случая (предоставить данные датчика для заданного промежутка времени через API). Должен ли я копать глубже и учиться, или мое время лучше потратить на поиск другой альтернативы?
У кого-нибудь есть опыт из аналогичного случая. Что работает для вас? Имейте в виду, что цена имеет значение, и "простое" решение может быть предпочтительнее, чем очень сложное, даже если сложное решение работает на несколько секунд лучше.
ОБНОВЛЕНИЕ 1: Чтобы ответить на некоторые вопросы в комментариях ниже.
- Есть примерно 12 000 датчиков, которые могут сообщать значение каждые 15 секунд. Это означает ~70 миллионов в день. На самом деле, не на всех этих датчиках включена "отчетность", поэтому мы не получаем столько данных каждый день, но, поскольку мы, естественно, хотим расширяться за счет большего количества клиентов и датчиков, мне действительно нужно решение, которое можно масштабировать до много миллионов значений датчиков в день.
- Разделение - это решение, и использование нескольких баз данных и / или нескольких таблиц - это то, что у меня есть, хотя да, но я рассматриваю это как запасной вариант, если / когда я исчерпал другие решения.
- Я прочитал еще немного о HBase, http://opentsdb.net/ и https://cloud.google.com/bigtable/ Google, и кажется, что Hadoop может быть реальной альтернативой, по крайней мере.
ОБНОВЛЕНИЕ 2: Сегодня я немного познакомился с хранилищем таблиц Azure и HDInsight (HDI). Нам не требуется особой гибкости запросов, поэтому я считаю, что хранилище таблиц Azure выглядит многообещающе. Как я уже упоминал, вытащить данные немного медленно из-за ограничения в 1000 элементов на запрос, но в моих тестах я думаю, что это достаточно быстро для наших случаев использования.
Я также наткнулся на OpenTSDB, что и побудило меня сначала попробовать HDI. После учебника по Azure ( https://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-tutorial-get-started/) я смог довольно быстро сохранить миллион записей и протестировать некоторые запросы. Запрашивать было намного быстрее, чем в хранилище таблиц Azure. Я мог даже снять 300 000 записей в одном запросе http (хотя заняло 30 секунд).
Но это стоит немного больше, чем хранилище таблиц Azure, и я думаю, что я могу оптимизировать свой код для повышения производительности запросов с помощью хранилища таблиц Azure (более точный ключ раздела и параллельный запуск запросов). Поэтому сейчас я склоняюсь к Azure Table Storage из-за простоты, цены и "достаточно хорошей" производительности.
В ближайшее время я собираюсь представить свои выводы внешнему консультанту, поэтому мне очень интересно узнать его мнение о вещах.
2 ответа
Таким образом, к концу этого года у вас будет 3 млрд записей (которые только начались). Каждая запись имеет 4 байта ID + 4 байта datetime + 8 байтов двойное значение, которое в сумме составляет 3*10^9 * (4+4+8) == 48 Гб.
Вы можете легко хранить и обрабатывать эти 48 ГБ в базе данных в памяти, такой как Redis, CouchBase, Tarantool, Aerospike. Все они с открытым исходным кодом, поэтому вам не нужно платить лицензионный сбор.
Могут быть некоторые дополнительные издержки при потреблении памяти на 10-30%, так что 48Gb может вырасти до 64Gb или чуть больше. Вы должны заполнить эти базы вашими реальными данными, чтобы выбрать наиболее экономичную для вашего случая.
Для всей рабочей нагрузки должно быть достаточно только одного физического компьютера, поскольку базы данных в памяти могут обрабатывать 100 000 запросов / обновлений в секунду на узел (действительное число зависит от вашего конкретного шаблона рабочей нагрузки). Для большей доступности я бы настроил два сервера - главный и подчиненный.
Цена моего физического сервера с 64Gb на борту до моего опыта составляет $2-3K. Обратите внимание, что вам даже не нужен диск SSD. Вращение должно быть хорошо, потому что все чтения попадают в оперативную память, а все записи только добавляются в журнал транзакций. Так работают базы данных в памяти. Я могу уточнить это, если у вас есть какие-либо вопросы.
3 миллиарда точек данных в год - довольно мало для современных баз данных временных рядов, таких как VictoriaMetrics. Он может сохранить такое количество точек данных менее чем за 3 минуты при скорости приема 19 миллионов выборок в секунду на компьютере с 64 виртуальными ЦП. Подробнее см. В этой статье.
Существуют производственные установки VictoriaMetrics с до 10 триллионами точек данных на один узел. И он масштабируется до нескольких узлов.
Поэтому я использовал все технологии, которые вы перечислили, так или иначе. Какие типы запросов вам нужно выполнить? Потому что, в зависимости от этого, вы можете управлять некоторыми решениями. Если вам не нужно запрашивать много разных способов, Table Storage может сработать для вас. Это будет очень хорошо масштабироваться, если вы будете следовать инструкциям, и дешево. Но если вы не можете просто выполнить точечный запрос для нужных вам данных, это может не сработать, или быть слишком сложным, чтобы быть хорошим вариантом. Opentsdb отлично подходит, если вам нужна база данных временных рядов. Будет ограничено количество запросов типа временных рядов. Есть много временных рядов, и есть много приложений, которые построены поверх него, таких как Bosun и Grafana, чтобы перечислить два, которые я использую. Последний вариант HDI - хранить данные в формате паркета (или в некотором столбцовом формате), создавать таблицу кустов поверх данных и выполнять запросы с помощью Spark SQL. На самом деле вам не нужно использовать Spark, вы также можете использовать Hive. Но то, от чего вам следует держаться подальше, - это традиционное Map Reduce, эта парадигма в наши дни практически мертва, и вы не должны писать в ней новый код. Вдобавок ко всему, если вы этого не знаете, то вокруг этого будет крутая кривая обучения. Я использую все технологии, и мы используем их для разных частей системы, и это зависит от требований чтения и записи приложения. Я бы посмотрел на использование искры и паркета на вашем месте, но это много нового инструмента, который может не понадобиться.