Смиренно прошу опытных джедаев просвятить в теоретических вопросах юного падавана. Собственно сабж: Просто так(в смысле сейчас никаких задач, где это нужно нет) решил почитать про создание распределенной среды. С проблемой кешированных данных а-ля файлы/память более менее понял. А вот теорию по масштабированию БД мозг упорно отказывается переваривать. Теория гласит, что(свободное цитирование) есть две разновидности репликации: Master/Master и Master/Slave. Дальше автор говорит, что схемы ведущий/ведущий создают проблемы в приложениях с интенсивной записью. Ну это в принципе понятно. Дальше идет описание схемы ведущий/ведомый, там автор говорит, что через ведущую базу нужно пускать все операции на изменение данных, а ведомые базы у нас будут юзатся только для чтения. Что тоже логично. Чуть дальше написано, что репликацию типа ведущий/ведомый наилучшим образом применима в ситуациях, когда объем чтения превышает объем записи. Тут мну заступаривает, т.е. ведущий/ведущий создает проблемы в приложениях с интенсивной записью, и ведущий/ведомый лучше использовать когда чтения больше чем записи. Да я прекрасно понимаю, что в почти во всех WEB приложениях запросы на чтение многократно превышают запросы на запись, но таки непонятно, если у нас все же очень много запросов на запись и от них не отказаться хоть ты тресни, что лучше использовать?
если у нас много-много запросов на запись, обычно делают еще промежуточную БД с разрушением нормальной формы. — она пишет «грязные» данные, БЕЗ индексов. Потом уже «чистая» БД разбирает неторопясь запросы на себя, обычно из бинарного лога, нормализует, возможно, еще раз ДЕнормализует в доп. таблицы для уменьшения нагрузки на чтение... Так делают в различных системах статистики и прочая.
Ага, значит все же есть и еще один вариант репликации. Хотя звучит он еще сложнее чем пляски вокруг 2-х ведущих) Для общего развития, не подскажешь так "на глазок" от скольки запросов на запись в секунду может понадобится вся эта канитель, с несколькими ведущими либо с промежуточной БД?
еще есть NDB кластер. Это тебе 440hz расскажет. Он хоть и тоже основан на существовании мастер-ноды, но выборки делает всем кластером. Это тоже специфичное скоростное решение, т.к. все таблицы хранятся в оперативе — что делает операции над ними очень быстрыми. Вот этого я тебе сказать не могу, к сожалению, у меня специфика работы несколько другая, нагрузку создают в основном не люди, а такие же машины, да и основная БД — оракл Да и вообще производительность БД меряется транзакциями в секунду, а не одиночными операциями
А, у НДБ есть еще преимущество - у него синхронная реплика, ессно. Т.е. данные для чтения доступны с любой машины сразу же, а не по после обновления реплики, как у асинхронных.
В двух словах... Запись не масштабируется репликацией в принципе. по определению. запись масштабируется только партишенингом, что уже отдельная тема Мастер/слейв обычно делают асинхронным, мастер/мастер - синхронным (опять же, это не значит что это обязательно так) - отсюда чисто логически вытекает все про производительность- Асинхронное быстрее освобождает запись, не дожидаясь всех нод. Синхронное на записи ждет подтверждение всех нод. Читать с мастер/мастер или мастер/слейв в принципе разницы нет по производительности, особо если записи немного. Писать при небольшом количестве записей - тоже разницы нет. Для интенсивной записи - лучше мастер/слейв... особо если поток записи не "ровный" а со всплесками.
флоппик, MiksIr. Тема масштабируемых систем оказалась куда более интересной чем казалась вначале, прямо таки завораживают Буду читать дальше. Огромное спасибо за информацию!