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

Не волнуйтесь, хорошие решения приходят!

Couchdb и Hypertable имеют открытый исходный код и все еще находятся в альфа-версии, но они явно предназначены для упрощения масштабирования на обычном программном обеспечении. Они работают довольно хорошо и могут изменить ваше представление о базах данных.

Кроме того, если вы можете позволить кому-то другому распространять за вас, Google AppEngine и Amazon SimpleDB — чрезвычайно дешевые службы распределенных баз данных, хотя они Оба сейчас находятся в стадии бета-тестирования, поэтому на них наложены строгие ограничения.

Oracle RAC вообще не масштабируется по горизонтали, поскольку все экземпляры Oracle используют одно и то же хранилище данных. Да, с помощью SAN вы можете получить БД большого размера, но она просто не масштабируется. Другими словами, Oracle RAC по-прежнему является масштабируемым подходом. Таким образом, для масштабирования или горизонтального масштабирования вы должны разделить свои данные по функциям, что означает размещение разных групп таблиц в разных базах данных; или разделите ваши данные на таблицу, что означает разделение одной таблицы на несколько подтаблиц с одной и той же схемой, но хранение в разных базах данных. Таким образом, вы получаете масштабируемое решение. На это есть много ресурсов. Шардинг некоторое время был модным словом в архитектуре веб-сайтов 2.0. сфера блога. Поскольку сегментирование напрямую не поддерживается самой базой данных, вам необходимо создать собственное решение. Но, как я уже сказал, уроков уже много. Для оракула возможна таблица разделов. Для mysql проверьте этот вопрос

Oracle RAC — настоящий кластер приложений

Это прекрасно работает, вы просто добавляете ящики в свой кластер. Вы можете переключиться с одного ящика на другой. Это не репликация, все ящики являются частью одного логического блока.

Это довольно затратно, конечно.

Существуют методы хранения, такие как JavaSpaces (или коммерческая реализация, такая как Gigaspaces), которые обеспечивают масштабируемый, быстрый и безопасный доступ к объектам.

Существуют также распределенные системы кэширования, такие как memcached, которые предлагают аналогичный подход.

Конечно, ни одна из них не является настоящей базой данных, но они могут работать в сочетании с базами данных, обеспечивая большую горизонтальную масштабируемость при наличии подходящей архитектуры. Настоящая проблема заключается в том, что если вам нужны все преимущества ACID, которые поставляются с базой данных, есть определенные неизбежные потери производительности. Единственный выход — определить биты, где ACID не нужен, и использовать другие технологии для обслуживания этих битов.

Oracle RAC — это Роллс-Ройс среди баз данных, позволяющий относительно легко добавлять дополнительные аппаратные узлы и переключать оборудование при отказе.

Однако затраты на стандартное оборудование будут ничтожно малы по сравнению с затратами на лицензии.

Почему вы считаете, что вам нужно горизонтальное масштабирование. Многопроцессорный основной сервер с 40 ГБ ОЗУ и хранилищем SAN может поддерживать установку БД очень большого размера.

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

Если вы пойдете по маршруту RAC, стоит помнить, что он не масштабируется по горизонтали вечно. Даже продавцы признают, что 90% клиентов rac имеют 4 узла или меньше. Как только вы сделаете больше, вы получите убывающую отдачу. Так что rac может сработать для вас, но это не обязательно будет ответом.

MySQL: http://www.mysql.com/why-mysql/scaleout.html< /а>

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

Маршрут Oracle для масштабирования между несколькими машинами называется Real Application Clusters (Oracle RAC). В других местах нет конца документации по этому вопросу; вы можете попробовать начать с http://www.oracle.com/database/rac_home.html.

Реальные кластеры приложений Oracle. Если вы хотите лучшего, то взгляните на него.

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

Все базы данных по горизонтали обойдутся очень дорого.

Если у вас нет мега $$ для решения проблемы, забудьте о RAC. Хотя это очень хорошо, это ОЧЕНЬ дорого, если вы масштабируетесь более чем на 2 узла.

MongoDB — одна из лучших баз данных с горизонтальным масштабированием.

Вы можете взглянуть на DashDB для OLAP — IBM сочетает его с Cloudant для OLTP. https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en