Hi!

Я разрабатываю систему, в которой несколько приложений параллельно должны делать INSERTы в БД в _одну простую таблицу_ с очень большой скоростью(логгинг). Ни одна СУБД с таким потоком вставок нормально справляться не будет. Возникла идея взять несколько компьютеров, поставить на каждый по СУБД и в каждой СУБД сделать нужную мне таблицу. Потом написать сервер, который стоит между клиентскими приложениями и СУБДами и который перенаправляет клиентские INSERT запросы попеременно на каждый из СУБДов, т.е. распределяет нагрузку. Вопросы: =)
1. Будет ли данная идея работать?
2. Может, такую систему уже кто-то строил или (еще лучше) кто-то уже написал такой load balancing сервер?


Заранее спасибо =)

Ребят, я понимаю, что можно писать в файл логов, а потом сливать в базу периодически. Но при таком подходе в конце каждого периода БД будет очень сильно нагружаться, это будет тормозить другие приложения, работающие с базой, а это неприемлемо.
Я хочу сделать так чтобы нагрузка была равномерной, без резких скачков или спадов.
Насчет того, сколько вставок: чем больше, тем лучше. Представьте, что я измеряю какую-нибудь физическую величину. Чем больше будет замеров, тем точнее можно проводить анализ. Колонок там около 15.
Кстати, я не знаток Oracle. Но там есть что-то под названием partitioning. Это не то что мне нужно?

tygraТак сколько записей планируется вставлять. В минуту/секунду...

Например, вставка 10 000 записей за 4 секунды вас устроит?

-- Tygra's --

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

Если кому-нибудь интересно, то вот то что я нашел по поводу распределенных систем и load balancing'a:
1. есть тулза, http://www.inspireonsoftware.com/Products-MyPQuery.htm
Это то, почти то что хочу писать я. Но эта тулза - только для SELECT
запросов по уже сделанным таблицам(да и то не все поддерживается). При этом она какая-то непонятная,
сырая и
стоит 400$.
2. В MySQL есть MERGE таблица. Это просто виртуальная таблица,
которая состоит из нескольких таблиц, одинаковых по схеме. Load
Balancing здесь опять таки не на INSERT'ах, а на SELECTах (типа можно
сделать 2 таблицы на разных физических дисках и соединить их в 1
MERGE таблицу, в результате выборка будет быстрее) Но - здесь не
кластер(одна БД)
3. Есть на gnu.org "SQL load balancer"(SQLB). но он опять не то что надо
делает. Он висит между клиентами и несколькими БД. Основная его суть
состоит в том, что он _постоянно_ поддерживает коннект к нескольким
БД, при этом если через неге начинают проходить много запросов к
какой-нибудь БД, то он создает дополнительное соединение к этой БД(или
наоборот убивает, если мало запросов). Выигрыш в скорости получается,
т.к. _нету_ времени задержки, связанного с подсоединением клиента к
базе данных. В ихней архитектуре клиентское приложение просто
записывает запрос в shared-memory сегмент и ставит флажок"надо
обработать". тут же демон подхватывает этот запрос и перенаправляет
его по нужному соединению.

В дополнение(если кому интересно)
есть еще C-JDBC с их подходом под названием RAIDb - Redundant Array of Inexpensive Databases. Они написали open-source софтину, которая опять же стоит между клиентом и СУБД любого типа. При этом можно выполнять partitioning между СУБДами до уровня таблиц(т.е. на каждом сервере СУБД хранится отдельная таблица), при этом для клиентского приложения все, понятное дело, прозрачно.
Но если пойти еще дальше(как я предлагал), то можно гранулировать данные до уровня отдельных row(а не до таблиц)
вот ссылка
http://www.objectweb.org/wws/d_read/marketing/public/projects/C-JDBC.pdf

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

эта тулза еще будет работать одновременно и как система интеграции

Хрен
А вообще кластеры уже придуманы достаточно давно. Даже для mysql. там есть встроенный кластер (тип таблиц ndb) (не production release, впрочем. То ли альфа то ли бета) и есть коммерческие решения для кластеров, например тут
Встроенный кластер MySQL - это несколько СУБДов с авторепликацией, цель кластера - создать высоконадежную систему. Ни о какой распределении нагрузки там речь не идет. Насчет того, что предлагает emicnetworks, я ничего сказать не могу, но на первый взгляд там опять же репликация на первом месте.
Возможно, я не прав. тогда поправьте меня