Однозначно могу сказать, что libslave подойдет в большинстве случаев, когда требуется получать обновления из базы MySQL, т.е. и в случае быстрого получения небольших обновлений. Единственное, что приходит в голову, когда получать все обновления не хочется — это в случае, когда данные меняются существенно быстрее, чем допустимый лаг для их потребителя, и объем изменений сравним с объемом самих данных. Например, если бесконечным потоком в таблицу льются поправки к каким-то коэффициентам, которые при этом медленно меняют сами коэффициенты, то выгоднее переселектить всю таблицу, чем получать все эти незначительные изменения.
Однако в случае, если таблица небольшого размера, и ее селект существенно быстрее того временного лага, который допустим для ее обновления в читателе, мы используем регулярный переселект всей таблицы, поскольку это проще в реализации — не надо продумывать логику, как обновить данные (т.е. поддержать операции insert/update/delete), надо просто скачать новые и выкинуть старые. Переселекчивать при этом можно раз в минуту, раз в секунду, чаще — сколько надо. Мы так поступаем с таблицами, которые содержат какие-то настройки. Этот случай частично подпадает под «быстрое получение небольших обновлений», хотя и в случае сильных изменений небольших таблиц работает не хуже.
Другой случай «быстрого получения небольших обновлений» — небольшие изменения больших таблиц. Понятно, что регулярный переселект тут не особо поможет, а libslave поможет, но вы спрашиваете, вероятно, про альтернативное решение без libslave, поскольку я упоминал, что сделать это «относительно легко». Поскольку решение, на мой взгляд, во многом зависит от конкретной задачи, попробую пофантазировать: пусть у нас есть один писатель, который пишет данные в таблицу, таблица большая, целиком находится в памяти большого количества демонов (т.е. БД используется ими как минимум для холодного старта), но обновляется по чуть-чуть, и нам хочется простого решения, как обновлять. Думаю, что самое простое по объему реализации, что я бы сделал, это вместе с записью данных в БД рассылал бы с писателя UDP пакеты с обновлениями всем зарегистрированным читателям. Поскольку обновлений немного, применять их должно быть просто, нагрузка будет небольшая во всех отношениях, пакеты не будут теряться, а обновления будут происходить синхронно на всех читателях. Это довольно упрощенное описание, но, по-моему, сделать такую рабочую модель можно.
С ростом количества изменений могут начаться проблемы несинхронности применения обновлений демонами — где-то какая-то задержка, кто-то лагнул, и мы уже не можем рассчитывать, что большой поток обновлений можно рассылать всем демонам одинаково. Приходится принимать во внимание состояние каждого из них, трекать, что кому посылать. И тут уже (хотя на самом деле даже раньше) удобно использовать libslave, поскольку там все эти проблемы решены, и каждый читатель получит свой поток изменений независимо от состояния других читателей и скорости, с которой он способен их применять.
Однозначно могу сказать, что libslave подойдет в большинстве случаев, когда требуется получать обновления из базы MySQL, т.е. и в случае быстрого получения небольших обновлений. Единственное, что приходит в голову, когда получать все обновления не хочется — это в случае, когда данные меняются существенно быстрее, чем допустимый лаг для их потребителя, и объем изменений сравним с объемом самих данных. Например, если бесконечным потоком в таблицу льются поправки к каким-то коэффициентам, которые при этом медленно меняют сами коэффициенты, то выгоднее переселектить всю таблицу, чем получать все эти незначительные изменения.
Однако в случае, если таблица небольшого размера, и ее селект существенно быстрее того временного лага, который допустим для ее обновления в читателе, мы используем регулярный переселект всей таблицы, поскольку это проще в реализации — не надо продумывать логику, как обновить данные (т.е. поддержать операции insert/update/delete), надо просто скачать новые и выкинуть старые. Переселекчивать при этом можно раз в минуту, раз в секунду, чаще — сколько надо. Мы так поступаем с таблицами, которые содержат какие-то настройки. Этот случай частично подпадает под «быстрое получение небольших обновлений», хотя и в случае сильных изменений небольших таблиц работает не хуже.
Другой случай «быстрого получения небольших обновлений» — небольшие изменения больших таблиц. Понятно, что регулярный переселект тут не особо поможет, а libslave поможет, но вы спрашиваете, вероятно, про альтернативное решение без libslave, поскольку я упоминал, что сделать это «относительно легко». Поскольку решение, на мой взгляд, во многом зависит от конкретной задачи, попробую пофантазировать: пусть у нас есть один писатель, который пишет данные в таблицу, таблица большая, целиком находится в памяти большого количества демонов (т.е. БД используется ими как минимум для холодного старта), но обновляется по чуть-чуть, и нам хочется простого решения, как обновлять. Думаю, что самое простое по объему реализации, что я бы сделал, это вместе с записью данных в БД рассылал бы с писателя UDP пакеты с обновлениями всем зарегистрированным читателям. Поскольку обновлений немного, применять их должно быть просто, нагрузка будет небольшая во всех отношениях, пакеты не будут теряться, а обновления будут происходить синхронно на всех читателях. Это довольно упрощенное описание, но, по-моему, сделать такую рабочую модель можно.
С ростом количества изменений могут начаться проблемы несинхронности применения обновлений демонами — где-то какая-то задержка, кто-то лагнул, и мы уже не можем рассчитывать, что большой поток обновлений можно рассылать всем демонам одинаково. Приходится принимать во внимание состояние каждого из них, трекать, что кому посылать. И тут уже (хотя на самом деле даже раньше) удобно использовать libslave, поскольку там все эти проблемы решены, и каждый читатель получит свой поток изменений независимо от состояния других читателей и скорости, с которой он способен их применять.
Надеюсь, что мне удалось ответить на ваш вопрос.