стратегия разделения базы данных - PullRequest
Новая
       15

стратегия разделения базы данных

5 голосов
/ 29 ноября 2009

Для продукта онлайн-рынка, находящегося в стадии разработки, у меня есть ситуация, которая требует реализации решения для разделения базы данных. Я новичок в шардинге и после прочтения постов на этом форуме я чувствую, что стратегия шардинга на основе каталогов с использованием бизнес-сущностей подойдет. Но я до сих пор не понимаю, как лучше всего применять денормализацию и синхронизацию данных с таким сомнительным решением. Будет 3 основных объекта: поставщик, клиент и заказ. Я планирую разделить базу данных на основе идентификатора поставщика, поскольку большая часть обработки данных заказа будет выполняться администраторами поставщика. Это обеспечит получение заказов для поставщика из одного экземпляра базы данных, исключая перекрестные выборки базы данных. Однако в этом случае, когда клиенты просматривают информацию о своем заказе, данные будут находиться в нескольких экземплярах базы данных и потребовать выборки из нескольких баз данных. Что обычно делается, когда такие сценарии возникают в заштрихованном решении.

Ответы [ 3 ]

11 голосов
/ 29 ноября 2009

Я думаю, что есть шанс 99,9%, что вам не нужен шардинг.

Вам нужен шард, если:

  • Скорость вставки / обновления вашей базы данных близка или превышает емкость самого высокого спецификационного сервера, который вы можете выгодно купить И
  • Вы уже обрабатываете большинство ваших запросов на чтение, создание отчетов, резервных копий и т. Д. Для реплицируемых подчиненных только для чтения
  • Вы выполнили функциональное разбиение, чтобы переместить все несущественные или не связанные с обновлениями рабочие нагрузки с вашего главного сервера

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

Читать

http://www.mysqlperformanceblog.com/2009/08/06/why-you-dont-want-to-shard/

2 голосов
/ 22 августа 2010

Разделение базы данных может быть чрезвычайно эффективным даже до того, как размер вашей базы данных достигнет нескольких ТБ. Основная причина, которую мы обнаружили, заключается в том, что соотношение памяти и процессора к диску заметно меняется, и продукты СУБД, такие как MySQL, действительно превосходно помещают в память самые последние использованные индексы и данные.

При возникновении проблемы с разделением данных этот метод может помочь.

  • Параллельный запрос (мы называем это запросами "Go Fish"). Благодаря этой идее вы можете одновременно запрашивать заказы у нескольких шардов и консолидировать результаты. Если все сделано правильно, это может быть очень эффективно.

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

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

1 голос
/ 22 августа 2010

Вы также можете попробовать nosql DB, такие как mongodb или Cassandra

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

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

...