Вот так я себе это представлял, но уже разочаровался в своей идее. Сдаётся мне они просто запутаются друг в друге. У лопнувшего шара тоже парусность нехилая.
Как насчёт такого варианта? Шар и парашют закреплены на противоположных концах одной веревки. Оборудование крепится посередине и свободно скользит от шара к парашюту. Шар лопается — парашют перетягивает канат на свою сторону.
Привет, команда. Предлагаю здесь в комментариях дополнительно перечислить варианты ошибок "что же могло пойти не так".
Так как индексный слой и сами данные обновляются не транзакционно, то индексный слой позволит увлекательно провести время, ковыряясь во всевозможных вариантах гонок.
- Например, таска из очереди может выполниться с отставанием (возможно никогда), и новые данные данные никто не найдёт.
- Или наоборот, таска отработает как надо, а запрос "add user data by id" - нет. Теперь старые данные никто не сможет найти, а новых не появиось.
- И, наконец, индексный слой может обновиться неконсистентно на разных стораджах (параллельные стрелочки "update search index" на картинке).
Нормальная запись в WAL будет только если указать специальный флаг в конфиге tarantool. Если его указать, то вся производительность на запись улетучится. Напомню, что без O_SYNC запись почти всегда будет в кеш ОС, а не на диск.
Что такое "нормальная запись в WAL" и зачем так нужна запись на диск? Если ваш ответ — чтобы данные не пропали случайно при блекауте, то фсинк тут мало на что влияет — сервер ведь и вместе с диском сгореть может. И тогда мы перейдем к разговору о репликации, желательно синхронной, но это будет уже совсем другая история.
Все эти рассуждения о быстроте имеет смысл вести только проведя перф тесты на системе, максимально приближенной к реальным условиям эксплуатации. На мой взгляд проблема undefined behavior куда серьёзнее.
table + 1 как раз указывает на дырку, в которую я могу добавить объект.
Это утверждение не верно. Ни в LuaJIT, ни в PUC-Rio Lua
table[index] = nil приводит к образованию дырок в массиве, и #table в этом случае — UB, о чём собственно рассказывает статья. Если у числовых индексов нет какого-то другого прикладного значения, то я бы советовал присмотреться к паттерну t[obj] = true (https://www.lua.org/pil/11.5.html).
Не обязательно. В статье речь шла про "нормальную" жизнь кластера. При обновлении могут быть разные случаи, все зависит от характера обновлений. В благоприятной ситуации можно обновить реплики, переключить лидеров и потом обновлять вторую половину
Вот так я себе это представлял, но уже разочаровался в своей идее. Сдаётся мне они просто запутаются друг в друге. У лопнувшего шара тоже парусность нехилая.
Как насчёт такого варианта? Шар и парашют закреплены на противоположных концах одной веревки. Оборудование крепится посередине и свободно скользит от шара к парашюту. Шар лопается — парашют перетягивает канат на свою сторону.
Отлаживать неотлаженные скрипты на проде - не лучшая затея.
Привет, команда. Предлагаю здесь в комментариях дополнительно перечислить варианты ошибок "что же могло пойти не так".
Так как индексный слой и сами данные обновляются не транзакционно, то индексный слой позволит увлекательно провести время, ковыряясь во всевозможных вариантах гонок.
- Например, таска из очереди может выполниться с отставанием (возможно никогда), и новые данные данные никто не найдёт.
- Или наоборот, таска отработает как надо, а запрос "add user data by id" - нет. Теперь старые данные никто не сможет найти, а новых не появиось.
- И, наконец, индексный слой может обновиться неконсистентно на разных стораджах (параллельные стрелочки "update search index" на картинке).
Что такое "нормальная запись в WAL" и зачем так нужна запись на диск? Если ваш ответ — чтобы данные не пропали случайно при блекауте, то фсинк тут мало на что влияет — сервер ведь и вместе с диском сгореть может. И тогда мы перейдем к разговору о репликации, желательно синхронной, но это будет уже совсем другая история.
Кажется вы ищите что-то типа web framework. Попробуйте почитать тут или тут, возможно это подойдёт.
Все эти рассуждения о быстроте имеет смысл вести только проведя перф тесты на системе, максимально приближенной к реальным условиям эксплуатации. На мой взгляд проблема undefined behavior куда серьёзнее.
Это утверждение не верно. Ни в LuaJIT, ни в PUC-Rio Lua
table[index] = nil
приводит к образованию дырок в массиве, и#table
в этом случае — UB, о чём собственно рассказывает статья. Если у числовых индексов нет какого-то другого прикладного значения, то я бы советовал присмотреться к паттернуt[obj] = true
(https://www.lua.org/pil/11.5.html).Что вы подразумаваете по "сайтом, написанном на луа"?
mikeus дело говорит. Идентичность таблиц проверяется по указателю — это те самые
table: 0x4082dfa8
в статье. Иными словамиИ при поиске ключа поведение будет то же самое.
Cdata — явление исключительно LuaJIT. В ванильном Lua его аналогов нет.
А получается, что все три случая дают разный результат.
Не обязательно. В статье речь шла про "нормальную" жизнь кластера. При обновлении могут быть разные случаи, все зависит от характера обновлений. В благоприятной ситуации можно обновить реплики, переключить лидеров и потом обновлять вторую половину