Решение распределенной базы данных?

Question

Эй. Я собираюсь создать базу данных, которая может стать действительно огромной.

Я использую стандартный mysql для большинства своих вещей, но эта конкретная проблема встанет на проблемы с ТБ, и я захочу сделать сотни запросов в секунду.

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

Имеет ли смысл распространять базу данных по нескольким компьютерам в моей интрасети, чтобы она могла масштабироваться с помощью CPU/Ram и т. Д., И если это так для этого или для решения баз данных для этого?

Спасибо за помощь! Я искал вопросы, связанные с этим, и не мог найти ничего такого жаль, если он уже был задан.

Answer 1

Масштабируемость базы данных - ОЧЕНЬ сложная проблема; есть много вопросов, которые входят во весь процесс.

Во-первых, рассмотрите наихудшие фрукты; есть ли у вас отдельные таблицы (или столбцы), которые будут содержать основную часть ваших данных? Столбцы, которые будут содержать BLOB, которые составляют> 4 МБ каждый? Они могут быть извлечены из базы данных и сохранены в системе хранения с плоскими файлами и просто указаны в базе данных; прямо там, что может занять много громоздких решений вплоть до управляемого уровня.

Если нет, у вас есть сильно разные шаблоны использования для разных подгрупп таблиц? Если это так, есть возможность для сегментирования вашей базы данных в разные функциональные базы данных, которые могут быть разделены на разные серверы. Хорошим примером этого является чтение данных, в основном данных, например, на веб-серверах, которые генерируются редко (думаю, пользовательские данные домашней страницы), но часто читайте; этот тип данных может быть разделен на базу данных (или, опять же, файл с ссылками), который отделен от остальных пользовательских данных).

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

Это касается только некоторых проблем, связанных с такими вещами. Стоит подумать о том, действительно ли вам нужна база данных, которая на самом деле будет огромной, или если вы просто пытаетесь использовать базу данных в качестве слоя сохранения. Если вы используете базу данных так же, как уровень персистентности, вы можете пересмотреть, действительно ли вам нужен реляционный характер базы данных вообще, или если вы можете уйти с меньшим реляционным наложением поверх более простого уровня сохранения. (Я говорю об этом, потому что большое количество решений, кажется, что они могли бы уйти с тонким реляционным слоем на большую инерционности слой, это стоит учесть.)

Answer 2

Хорошо, сначала я должен указать вам на here. Я не Думаю, что MySQL будет работать так, как вы хотите. У меня плохое чувство, что, когда я говорю, что вам нужно заглянуть в установку Oracle, вы скажете: «У нас нет денег для этого». Но, когда я говорю, получите последний/самый большой SQL-сервер, вы скажете: «У нас нет оборудования, которое потребуется для его реализации». Я боюсь, что терабайты просто плоские, чтобы подавить вашу установку MySQL.

Answer 3

Создается новое поколение баз данных NewSQL для решения именно проблемы распределения ресурсов по нескольким серверам.База данных Clustrix (которая была построена с нуля, чтобы быть заменой MySQL) является одним из примеров, который обеспечивает почти линейный масштаб - по мере того, как у вас заканчивается процессор/память, вы можете просто добавлять узлы.

Answer 4

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

Горизонтальная масштабируемость; возможность масштабирования базы данных по горизонтали (aka scale-out) является хорошей методикой для решения проблемы очень больших таблиц и баз данных.