Как спасти ссылочную целостность с несколькими базами данных

Question

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

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

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

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

У кого-нибудь есть предложения по смягчению этой проблемы или есть другие предложения по дизайну?

Answer 1

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

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

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

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

Answer 2

Дайте мне посмотреть, могу ли я дать лучший обзор проблемной области:

В поисках решения для "предприятия", где n производственных площадок будут увеличиваться.

Мы обрабатываем данные для создания документов в Интернете и для печати. ​​

Система будет управлять потоком процессов для передачи файла данных из представления (через централизованный веб-сайт) на принтер или в Интернет или в оба.

Каждый производственный сайт имеет своих клиентов и т. Д. Вся эта информация будет храниться в базе данных. Большая часть администрирования этой информации будет происходить на центральном сайте

Мы обрабатываем все данные на одном сервере из-за лицензионных ограничений в используемом нами программном обеспечении.

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

Для огромного объема данных используется наш веб-инструмент. Нам нужно хранить поисковые индексы для каждого документа, который мы производим для Интернета. Это становится довольно большим довольно быстро. Эти записи не сохраняются вечно, но они будут большими (примерно 500 миллионов строк), по крайней мере, большую часть времени.

Я подумал, что избавиться от проблемы с размером таблицы - это отдельная БД, а также возможность разделить рабочие сайты на разных серверах.

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

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

Я бы даже не рассматривал базы данных, если бы рост не был неизвестен.

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

Я прошу прощения за рассеянный ответ. Это был 12-часовой рабочий день. Я действительно мог бы продолжаться вечно, но, надеюсь, это в любом случае даст немного больше понимания.

Пример отношения с одной БД

сайт имеет много клиентов у клиентов много отправителей податели имеют много представлений У подачи есть много документов документы имеют много индексов

Чтобы я мог легко посчитать количество документов для клиента с помощью объединений

Answer 3

Если вы правильно понимаете, вы хотите (возможно) использовать триггеры для проверки, для каждой вставки / обновления / удаления, сохраняется ли ссылочная целостность на удаленных базах данных?

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

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

Но не поймите меня неправильно, я на 100% поддерживаю данные в надежном и надежном состоянии, но иногда это не всегда может быть принудительно выполнено.

Но, как было сказано ранее, без дополнительной информации о решении сложно дать совет ...:)

Answer 4

Сколько данных вы говорите? Вам действительно нужна эта архитектура? БД могут управлять большой емкостью.

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

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

Это также другая проблема для таблиц, которые поддерживаются исключительно на бэкэнде (скажем, в целях целостности данных), по сравнению с теми операционными таблицами, которые пользователи часто обновляют и часто добавляют. Более «статические» таблицы можно считать просто статичными. Наличие надежной процедуры для обновления их по всем узлам, если это необходимо, а в идеале - редко.

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

Answer 5

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

В противном случае вы должны переместить свою ссылочную целостность вверх на уровень - в приложение.