Вопрос масштабируемости SQL сервера

Question

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

одна запись будет содержать текстовые данные и метаданные о текстовом документе.

pl, помогите мне понять ограничения хранения. Может ли SQL или оракул базы данных поддерживать такое количество данных, или мне нужно искать какое-то другое решение на основе файловой системы? Какие у меня варианты?

Поскольку центральный сервер должен обрабатывать входящую нагрузку от многих клиентов, как будут масштабироваться параллельные вставки и поиск? Как распределить данные по нескольким базам данных или таблицам? Я мало знаком с особенностями базы данных для такой масштабируемой среды.

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

общий объем данных будет превышать 1000 ТБ.

спасибо.

Answer 1

1 триллион +

одна запись будет содержать текстовые данные и метаданные о текстовом документе.

pl, помогите мне понять ограничения хранения

Надеюсь, у вас БОЛЬШОЙ бюджет на оборудование.Это большой размер, как в «миллионах».

Триллион документов при общем объеме хранения 1024 байта на один документ (ОЧЕНЬ маловероятно, когда вы произносите текст) имеет размер около 950 терабайт данных.Ограничения хранилища означают, что вы говорите о высоком конце SAN здесь.Использование не избыточной настройки дисков объемом 2 ТБ, что составляет 450 дисков.Сделать математику.Добавление избыточности / рейда к этому, и вы говорите о крупных аппаратных инвестициях.Это предполагает только 1 КБ на документ.Если вы используете в среднем 16 кг данных, это ... 7200 2 ТБ дисков.

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

Что бы это ни было, требования к хранилищу / резервному копированию превосходны.Проект Лагре здесь, большой бюджет.

Нагрузка ввода-вывода должна быть другой проблемой - с точки зрения аппаратного обеспечения.Вам понадобится большая машина и вы получите тонну пропускной способности ввода-вывода.Я видел 8-гигабитные ссылки, перегруженные на SQL-сервере (питаемом HP eva с 190 дисками), и я могу представить, что вы запустите нечто подобное.Вам понадобится как можно больше аппаратных средств, насколько это технически возможно, независимо от цены, если только вы не храните капли снаружи.

Сжатие строк SQL может оказаться ОЧЕНЬ удобным.Полнотекстовый поиск будет проблемой.

общий объем данных будет превышать 1000 ТБ.

Нет.Шутки в сторону.Это будет больше, я думаю.1000 ТБ будет предполагать, что документы маленькие - как XML-форма проездного билета.

Answer 2

В пространстве SQL Server вы можете взглянуть на Параллельное хранилище данных SQL Server , которое предназначено для приложений объемом 100 ТБ / петабайт.Teradata, Oracle Exadata, Greenplum и т. Д. Также должны быть в вашем списке.В любом случае вам понадобится помощь специалиста, чтобы выбрать и спроектировать решение, поэтому вам следует задать этому человеку вопрос, который вы задаете здесь.

Answer 3

Согласно странице MSDN Ограничения SQL Server , он может вместить 524 272 терабайта в одной базе данных - хотя он может вместить только 16 ТБ на файл, поэтому для 1000 ТБ вы захотите реализовать разделение . Если сами файлы имеют большой размер и просто будут рассматриваться как двоичные двоичные объекты, вам также может потребоваться посмотреть FILESTREAM , который фактически сохраняет файлы в файловой системе, но поддерживает такие понятия SQL Server, как как транзакции, резервное копирование и т. д.

Все вышеперечисленное относится к SQL Server. Другие продукты (например, Oracle) должны предлагать аналогичные возможности, но я не могу перечислить их.

Answer 4

Когда дело доходит до базы данных, это довольно сложно, и для достижения производительности может потребоваться несколько компонентов, таких как Redis Cache, Sharding, Read replicas и т. Д. В статье ниже приводится упрощенная масштабируемость БД.

http://www.cloudometry.in/2015/09/relational-database-scalability-options.html