Комментарии: 6
🦾
Речь пойдет преимущественно про master-slave репликацию
Основные ее задачи (1) иметь возможность восстановиться после падения, (2) разгрузить основную БД с чтения
Топлогия – это связи этих master-slave узлов базы (представьте себе граф / дерево это и будет топология)
У репликации среднестатистически есть 2 уровня надежности: async и sync
Проблема sync в том, что БД будет задерживать подтверждение транзакции, пока не подтвердит реплика, проблема async, что при падении мастера часть транзакций будет отсутствовать в реплике, но при этом нет задержки на подтверждение транзакций
“Средняя по больнице” топология это когда у вас 1 master и 2 slave на async репликации в разных датацентрах
Так вот, по факту, мы можем делать топологию, в которой первые 1-2 ноды в sync, но находятся близко к мастер базе (в рамках как минимум одного датацентра), а потом 1-n нод в async
С одной стороны, у нас есть надежная sync репликация с наименьшей задержкой, потому что реплики лежат максимально близко к мастеру, с другой есть async реплики, которые можно положить достаточно далеко для надежности, но данные в них понадобятся только для чтения не в realtime
Не могу сказать, что советую всем и сразу, скорее, надо иметь ввиду такую возможность
Видео по теме
Основные ее задачи (1) иметь возможность восстановиться после падения, (2) разгрузить основную БД с чтения
Топлогия – это связи этих master-slave узлов базы (представьте себе граф / дерево это и будет топология)
У репликации среднестатистически есть 2 уровня надежности: async и sync
Проблема sync в том, что БД будет задерживать подтверждение транзакции, пока не подтвердит реплика, проблема async, что при падении мастера часть транзакций будет отсутствовать в реплике, но при этом нет задержки на подтверждение транзакций
“Средняя по больнице” топология это когда у вас 1 master и 2 slave на async репликации в разных датацентрах
Так вот, по факту, мы можем делать топологию, в которой первые 1-2 ноды в sync, но находятся близко к мастер базе (в рамках как минимум одного датацентра), а потом 1-n нод в async
С одной стороны, у нас есть надежная sync репликация с наименьшей задержкой, потому что реплики лежат максимально близко к мастеру, с другой есть async реплики, которые можно положить достаточно далеко для надежности, но данные в них понадобятся только для чтения не в realtime
Не могу сказать, что советую всем и сразу, скорее, надо иметь ввиду такую возможность
Видео по теме
I
Вот тебе по теме только что увидел очень необычное решение на wasm, я бы сказал нестандартное мышление порождает такие интересные концепции https://github.com/RReverser/wasm-bindgen-rayon
I
🦾 IT-Качалка Давида Шекунца 💪
Речь пойдет преимущественно про master-slave репликацию
Основные ее задачи (1) иметь возможность восстановиться после падения, (2) разгрузить основную БД с чтения
Топлогия – это связи этих master-slave узлов базы (представьте себе граф / дерево это и будет топология)
У репликации среднестатистически есть 2 уровня надежности: async и sync
Проблема sync в том, что БД будет задерживать подтверждение транзакции, пока не подтвердит реплика, проблема async, что при падении мастера часть транзакций будет отсутствовать в реплике, но при этом нет задержки на подтверждение транзакций
“Средняя по больнице” топология это когда у вас 1 master и 2 slave на async репликации в разных датацентрах
Так вот, по факту, мы можем делать топологию, в которой первые 1-2 ноды в sync, но находятся близко к мастер базе (в рамках как минимум одного датацентра), а потом 1-n нод в async
С одной стороны, у нас есть надежная sync репликация с наименьшей задержкой, потому что реплики лежат максимально близко к мастеру, с другой есть async реплики, которые можно положить достаточно далеко для надежности, но данные в них понадобятся только для чтения не в realtime
Не могу сказать, что советую всем и сразу, скорее, надо иметь ввиду такую возможность
Видео по теме
Основные ее задачи (1) иметь возможность восстановиться после падения, (2) разгрузить основную БД с чтения
Топлогия – это связи этих master-slave узлов базы (представьте себе граф / дерево это и будет топология)
У репликации среднестатистически есть 2 уровня надежности: async и sync
Проблема sync в том, что БД будет задерживать подтверждение транзакции, пока не подтвердит реплика, проблема async, что при падении мастера часть транзакций будет отсутствовать в реплике, но при этом нет задержки на подтверждение транзакций
“Средняя по больнице” топология это когда у вас 1 master и 2 slave на async репликации в разных датацентрах
Так вот, по факту, мы можем делать топологию, в которой первые 1-2 ноды в sync, но находятся близко к мастер базе (в рамках как минимум одного датацентра), а потом 1-n нод в async
С одной стороны, у нас есть надежная sync репликация с наименьшей задержкой, потому что реплики лежат максимально близко к мастеру, с другой есть async реплики, которые можно положить достаточно далеко для надежности, но данные в них понадобятся только для чтения не в realtime
Не могу сказать, что советую всем и сразу, скорее, надо иметь ввиду такую возможность
Видео по теме
как раз тут CockroachDB анонсировали интересную новую систему реплицирования данных MOLT Live Migration Service
🦾
Ivan Zhuravlev
как раз тут CockroachDB анонсировали интересную новую систему реплицирования данных MOLT Live Migration Service
Инструмент по миграции со старых систем на CDB… Вау, ну ребята реально понимают что нужно бизнесу
🦾
Ivan Zhuravlev
Вот тебе по теме только что увидел очень необычное решение на wasm, я бы сказал нестандартное мышление порождает такие интересные концепции https://github.com/RReverser/wasm-bindgen-rayon
Не понимаю одного: это для realtime вычислений или все-таки для больших данных?
Мне просто интересно, если это real-time значит мы ещё на шаг ближе к полноценным играм в браузере на webassembly
Мне просто интересно, если это real-time значит мы ещё на шаг ближе к полноценным играм в браузере на webassembly
I
🦾 IT-Качалка Давида Шекунца 💪
Не понимаю одного: это для realtime вычислений или все-таки для больших данных?
Мне просто интересно, если это real-time значит мы ещё на шаг ближе к полноценным играм в браузере на webassembly
Мне просто интересно, если это real-time значит мы ещё на шаг ближе к полноценным играм в браузере на webassembly
С играми у мозиллы экспериментс помоему есть проект, где давно уже клепают под все новые модные технологии типа wasm, webgl, webgpu, webvr и т.п.
На сколько помню какой-то из движков типа UE старый или Unity портировали или пытались, но был какой-то проект по конвертации десктопных игр в веб и тогда я помню много игр переносили.
Вот нашёл статью как раз там все рассуждения об играх на wasm https://hacks.mozilla.org/2017/07/webassembly-for-native-games-on-the-web/
На сколько помню какой-то из движков типа UE старый или Unity портировали или пытались, но был какой-то проект по конвертации десктопных игр в веб и тогда я помню много игр переносили.
Вот нашёл статью как раз там все рассуждения об играх на wasm https://hacks.mozilla.org/2017/07/webassembly-for-native-games-on-the-web/