> Логика в самой БД плохо работает когда эта логика делает еще какое-то IO кроме БД.
Кооперативная многозадачность. Тарантул йилдит в этом случае.
> Это провал
Ой да ну вы так не пугайте. Есть уже и синхронная репликация.
Ну и в целом, спорить на тему того, работоспособна/эффективна ли система, активно использующаяся в продакшене, конечно, можно, но это немного бессмысленно. Поэтому я, пожалуй, завершаю разговор. Рекомендую почитать tarantool.io. После этого многие вопросы отпадут сами собой.
Если tarantool не пишет индексы на диск, то это ещё один компромис, о котором нужно говорить.
На роль волшебного продукта Tarantool не претендует. Претендует на то, что он удобен и эффективен для highload. Естественно, все достигается за счет компромиссов.
Сервер приложений в чем-то лучше скриптов и хранимок в БД?
Ну как вам сказать. Полноценный язык программирования с реактивным джитом и развитой экосистемой против процедурного PL/SQL…
Я правильно понимаю, что репликация работает в pull режиме, то есть реплики запрашивают данные с мастера когда им удобно?
Да, асинхронная репликация работает так:
A replica gets all updates from the master by continuously fetching and applying its write ahead log (WAL).
Не важно тарантул или PG, если железо перегружено, вам ничего не поможет.
Запись в b-дерево — большой объем холостой работы не зависимо от того, в каком режиме она выполняется — синхронном или асинхронном. С PG отказ железа наступит при существенно меньшей нагрузке, не?
Еще у нас есть сервер приложений. Код работает в одном адресном пространстве с БД. racktear может в статью еще нагрузочный пример на Lua добавить? :)
Ой, все. «Сейчас я вам за 5 минут из своей Посгри сделаю Тарантул (<place-here-your-favourite-system-name>)». Это мы уже слышали.
А что асинхронная нагрузка iops-ы не поднимает? Любим обогревать космос или хотим проверить через какое время при стабильно высокой нагрузке очередь на запись дорастет до таких размеров что диски лягут?
Далее. Кэш не есть in-memory DB! Кэш надо как минимум один раз считать с диска (предварительно поискав там и обломавшись). Ну и классическая проблема всех кэшей — это синхронизация. Отредактировали страницу — флашим ее на диск и дальше по схеме…
Вот только тогда прибегут любители PG и начнут тыкать в async commit, который ровно это и делает и начнут задавать неудобные вопросы о преимуществе перед классической БД.
Извините, PG пишет на диск в B-tree, а Tarantool только в WAL. Это большая разница. Далее, PG читает данные с диска, а Тарантул из RAM. Вот таким нехитрым способом Тарантул захватывает мир обеспечивает высокое быстродействие.
Действительно, для простоты изложения я опустил некоторые детали, что могло вызвать вопросы у разработчиков с небольшим опытом использования Tarantool. Добавил инструкции по созданию модулей и вызова функций из них. Спасибо за замечание!
Основная цель высокоуровневой репликации — достичь большей гибкости при передаче данных. Это универсальный подход, способный работать даже в распределенных/гетерогенных системах (см. рис. 3). Поэтому HTTP здесь — больше преимущество, чем недостаток. Количество трафика при использовании JSON на самом деле не является большой проблемой, т.к. сжатый JSON часто сопоставим по размеру с бинарным представлением данных.
Экономия трафика по сравнению с низкоуровневой репликацией может быть получена за счет гибкости подхода. Например, в БД 1000 таблиц, а я хочу передавать только 10.
Если речь идет о передаче данных между Тарантулами и для высокоуровневой репликации хочется использовать именно бинарный протокол, то для этих целей есть модуль net.box. Но такое решение будет менее универсальным.
Высокоуровневая репликация не является решением «из коробки». Если нужно что-то более компактное в плане протокола, только между Тарантулами внутри кластера и «из коробки», то ваш выбор — встроенная (низкоуровневая) репликация.
https://en.wikipedia.org/wiki/Disk_buffer#Write_acceleration
Кооперативная многозадачность. Тарантул йилдит в этом случае.
> Это провал
Ой да ну вы так не пугайте. Есть уже и синхронная репликация.
Ну и в целом, спорить на тему того, работоспособна/эффективна ли система, активно использующаяся в продакшене, конечно, можно, но это немного бессмысленно. Поэтому я, пожалуй, завершаю разговор. Рекомендую почитать tarantool.io. После этого многие вопросы отпадут сами собой.
На роль волшебного продукта Tarantool не претендует. Претендует на то, что он удобен и эффективен для highload. Естественно, все достигается за счет компромиссов.
Ну как вам сказать. Полноценный язык программирования с реактивным джитом и развитой экосистемой против процедурного PL/SQL…
Да, асинхронная репликация работает так:
A replica gets all updates from the master by continuously fetching and applying its write ahead log (WAL).
Запись в b-дерево — большой объем холостой работы не зависимо от того, в каком режиме она выполняется — синхронном или асинхронном. С PG отказ железа наступит при существенно меньшей нагрузке, не?
Еще у нас есть сервер приложений. Код работает в одном адресном пространстве с БД. racktear может в статью еще нагрузочный пример на Lua добавить? :)
А что асинхронная нагрузка iops-ы не поднимает? Любим обогревать космос или хотим проверить через какое время при стабильно высокой нагрузке очередь на запись дорастет до таких размеров что диски лягут?
Далее. Кэш не есть in-memory DB! Кэш надо как минимум один раз считать с диска (предварительно поискав там и обломавшись). Ну и классическая проблема всех кэшей — это синхронизация. Отредактировали страницу — флашим ее на диск и дальше по схеме…
Извините, PG пишет на диск в B-tree, а Tarantool только в WAL. Это большая разница. Далее, PG читает данные с диска, а Тарантул из RAM. Вот таким нехитрым способом Тарантул
захватывает миробеспечивает высокое быстродействие.