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

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

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

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

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

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

Oracle RAC - кластер реальных приложений

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

Конечно, это довольно дорого.

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

Однако стоимость вашего обычного оборудования будет меньше, чем стоимость лицензии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MongoDB одна из лучших баз данных, масштабируемая по горизонтали.

Вы можете посмотреть DashDB для OLAP - IBM объединяет его с Cloudant для OLTP. https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en