Данный:
Ожидается, что через пару лет объем данных превысит петабайты.
Полный набор типов записей, приложений и запросов заранее неизвестен. Ожидается, что заинтересованные стороны будут продолжать находить новые способы использования данных, как это обычно происходит с большой базой данных.
Система будет работать на серийном оборудовании, распределенном по нескольким дата-центрам.
Решения с открытым исходным кодом предпочтительнее, если это вообще возможно, по прагматическим причинам: желание иметь возможность изменять код при необходимости и не желать попасть в слабую позицию на переговорах с поставщиком.
Какой механизм базы данных лучше всего использовать?
Если бы мы говорили только о терабайтах, я бы просто указал Postgres и все, но я понимаю, что стандартная база данных SQL не может масштабироваться до петабайтов.
Мне дали понять, что Yahoo модифицировала Postgres до такого масштаба. Мне кажется, что это в основном повлечет за собой передачу нагрузки от программистов, пишущих код приложения (которые теперь получают обычные преимущества, заключающиеся в том, что им не нужно так сильно беспокоиться о том, чтобы никогда не пропустить какие-либо ошибки, потому что реляционная база данных многое делает для обеспечения соблюдения правил). согласованность) для тех, кто поддерживает механизм базы данных (прозрачное предоставление этих гарантий вместе с быстрыми SQL-запросами в таком масштабе является сложной проблемой).
В качестве альтернативы можно было бы взять хороший движок базы данных NoSQL и настроить его по мере необходимости. Это возлагает больше ответственности на разработчиков приложений, чтобы они никогда не совершали ошибок, но позволяет легче быть уверенным в том, что любое данное приложение может быть сделано достаточно быстро при достаточном усилии.
Считается ли первый вариант надежно жизнеспособным в наши дни?
Является ли второй вариант типичной практикой? Если да, то какой механизм NoSQL лучше всего подходит для этого сценария?
Есть ли третий вариант, который мне не хватает?
Я чувствую, что было бы безответственно рекомендовать что-то, основываясь на предоставленных мелких деталях, но, поскольку мои мысли не уместились в комментарии, я опубликую это здесь.
Для варианта использования OLTP: если вы считаете, что Postgres хорошо подходит с точки зрения функций и для вашей команды разработчиков, и вас беспокоит только масштабирование, метрикой, которую вы должны учитывать, является размер рабочих данных (количество данных, запрашиваемых OLTP-запросы) и количество TPS (транзакций в секунду) и их скорость чтения/записи), а не общий объем данных, которые будет накапливать система.
У меня нет личного опыта масштабирования Postgres, но говорят, что 1 000 000 запросов на чтение/с достижимы, если данные помещаются в память, как и 10 000 операций записи/с . Вы можете поместить кеши перед БД, чтобы улучшить производительность чтения, и реализовать сегментирование (через расширения) для масштабирования записи.
Я пытаюсь избежать дебатов NoSQL и RDBMS, но для тех, кто больше всего заботится о масштабируемости, первая может считаться типичной практикой...
Для вариантов использования хранилища данных/отчетности (запустите этот SQL на терабайтах данных за минуту) существует класс решений, называемых «базами данных MPP» (если вы работаете с Postgres, возможно, вы слышали о Greenplum). Они разбивают данные и выполняют запрос на нескольких (относительно высокопроизводительных) узлах параллельно, но они не оптимизированы для обработки большого количества легковесных запросов.
Если вам нужен экономичный способ хранения данных для аналитики и/или вы не хотите ограничиваться одним инструментом, вам может быть интересна экосистема Hadoop. Вы теряете некоторую эффективность (и тратите ресурсы на накопление опыта), но получаете возможность запускать произвольные решения для «больших данных» (ML, потоковая передача, множество механизмов БД) или собственный код в своем кластере.
Взгляните на CockroachDB. Вы говорите о больших данных, и платформа должна поддерживать серьезное масштабирование.
https://www.cockreachlabs.com/
Это, вероятно, хорошо из коробки, и у него хорошее сообщество с открытым исходным кодом.
Мог говорит восстановить Монику
Николай
руллес