Я не сварщик, но HBase все-таки не такой уж и тупой.
Мастером для данных является каждый регион сервер (для регионов, за которые он отвечает). Соответственно, при падении регион сервера будет недоступна часть данных, пока эти регионы не назначатся на другие регион сервера.
Мастер кластера отвечает за изменение метаданных. За хранение отвечает Сторож Зоопарка. Соответственно, если упал мастер кластера, то не получится поменять состав кластера или схему данных. Однако читать и писать данные вы сможете.
Конечно, если упал мастер кластера и регион сервер одновременно, то данные не будут доступны пока кого-нибудь из них не поднимете, т.к. без мастера кластера регионы не переедут на другие регион-сервера.
И для мастера кластера и для регион-серверов вроде как в последних версиях можно назначать слейвов, что сильно уменьшает время простоя.
умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать.
Ну зачем же так обобщать? PostgreSQL довольно сложно уронить по OoM. По крайней мере, одним запросом. Т.к он может сбрасывать промежуточные данные на диск. Конечно, и у него бывают промашки, но вроде бы редко.
after insert — это не тоже самое, что before commit. Между after insert и commit есть промежуток времени, в который может прилететь rollback.
если используете честный before commit, то не можете в одной транзакции вставить связанные документы. Не знаю, правда, нужно ли это в контексте 1С и подобных систем.
Правда, в некоторых локациях возможность пострелять из-за дверей тоже была. Не всегда, правда, это помогало, т.к. монстров иногда было так много, что шквального огня не хватало, чтобы удержать их за дверями.
В том же пресловутом (и горячо мною любимом) Serious Sam эту проблему решали довольно примитивно и эффективно: двери за тобою захлопывались, и только после этого монстры появлялись/выходили из-за укрытий.
Впринципе, там были практически все описанные тут приёмы + закрытие дверей :-)
Эхх… любимый безбашенный Kill 'em All «пяться и стреляй»
В ruby 1.8.х у строки был метод each (практически аналог __iter__ в руби) https://ruby-doc.org/core-1.8.7/String.html#method-i-each, который итерировался по "линиям" (и был алиасом к each_line). Это лучше, чем по символам, но всё равно мешал.
В 1.9.1 его выкинули. Оставили each_line, each_byte и each_char.
Простите пожалуйста, а что такое col based репликация?
Я знаю, что сторадж бывает column based. Но про репликацию не слышал.
А вообще, если я правильно помню, тарантул реплицирует операции: т.е. если был update c=c+1 where id=100, то только эта операция и будет реплицирована. Могу ошибаться.
Добавлю: в Speck нет никаких таблиц замены. Это Xor-Add-Rotate алгоритм в чистом виде. И настолько простой, что экспертам трудно было поверить в его надежность. Хотя с моей точки зрения, простота является признаком надежности. Но я не эксперт.
Ну и, да, конструкция напрягает тем, что для шедулинга ключа и перемешивания текста используется одинакрвфй блок операций.
Однако, полноценный Speck пока что не взломан, хотя есть теоретическая (читай, практически не применимая) атака на 18 раундов из 32.
Во-первых, я сразу в скобочках уточнил: с точки зрения Garbage Collector. Я ведь отвечал на замечание, что "иммутабельность вообще упрощает сборку мусора".
Во-вторых, я привел пример, доказывающий, что Хаскель не истинно immutable, т.к. в понастоящему immutable языке нет возможности организовать двухсвязный список, да и вообще любую структуру с циклами.
Со вторым моментом я могу несколько ошибаться, потому что здесь многое зависит от принятых определений. Если сказать, что хаскель настолько крут, что позволяет сконструировать иммутабельную структуру с циклами, то наверное я не прав.
Однако в хаскеле очень много мутабельности: все ленивые вычисления реализованы через мутабельность (с точки зрения GC).
Говорят, что с помощью ленивости в хаскеле возможно реализовать даже двухсвязные и циркулярные списки, что невозможно в языке с истинной иммутабельностью (например, в Erlang).
Я не сварщик, но HBase все-таки не такой уж и тупой.
Мастером для данных является каждый регион сервер (для регионов, за которые он отвечает). Соответственно, при падении регион сервера будет недоступна часть данных, пока эти регионы не назначатся на другие регион сервера.
Мастер кластера отвечает за изменение метаданных. За хранение отвечает Сторож Зоопарка. Соответственно, если упал мастер кластера, то не получится поменять состав кластера или схему данных. Однако читать и писать данные вы сможете.
Конечно, если упал мастер кластера и регион сервер одновременно, то данные не будут доступны пока кого-нибудь из них не поднимете, т.к. без мастера кластера регионы не переедут на другие регион-сервера.
И для мастера кластера и для регион-серверов вроде как в последних версиях можно назначать слейвов, что сильно уменьшает время простоя.
Ну зачем же так обобщать? PostgreSQL довольно сложно уронить по OoM. По крайней мере, одним запросом. Т.к он может сбрасывать промежуточные данные на диск. Конечно, и у него бывают промашки, но вроде бы редко.
Вот такой serial точно дырки будет иметь т.к. он не before commit.
Нет, не решил:
Впринципе, там были практически все описанные тут приёмы + закрытие дверей :-)
Эхх… любимый безбашенный
Kill 'em All«пяться и стреляй»Впрочем, если вся тестовая база влезала в память, то и ладно.
В ruby 1.8.х у строки был метод
each(практически аналог__iter__в руби) https://ruby-doc.org/core-1.8.7/String.html#method-i-each, который итерировался по "линиям" (и был алиасом кeach_line). Это лучше, чем по символам, но всё равно мешал.В 1.9.1 его выкинули. Оставили
each_line,each_byteиeach_char.Простите пожалуйста, а что такое col based репликация?
Я знаю, что сторадж бывает column based. Но про репликацию не слышал.
А вообще, если я правильно помню, тарантул реплицирует операции: т.е. если был
update c=c+1 where id=100, то только эта операция и будет реплицирована. Могу ошибаться.Добавлю: в Speck нет никаких таблиц замены. Это Xor-Add-Rotate алгоритм в чистом виде. И настолько простой, что экспертам трудно было поверить в его надежность. Хотя с моей точки зрения, простота является признаком надежности. Но я не эксперт.
Ну и, да, конструкция напрягает тем, что для шедулинга ключа и перемешивания текста используется одинакрвфй блок операций.
Однако, полноценный Speck пока что не взломан, хотя есть теоретическая (читай, практически не применимая) атака на 18 раундов из 32.
И если вы почитаете про Garbage Collector в GHC, аы узнаете, что даже "мутабельная ровно 1 раз" переменная сильно усложняет ему жизнь.
Я отвечал на замечание "иммутабельность вообще упрощает сборку мусора".
И, смотрите мой ответ https://m.habr.com/ru/post/438970/comments/?reply_to=19737594#comment_19737792
Во-первых, я сразу в скобочках уточнил: с точки зрения Garbage Collector. Я ведь отвечал на замечание, что "иммутабельность вообще упрощает сборку мусора".
Во-вторых, я привел пример, доказывающий, что Хаскель не истинно immutable, т.к. в понастоящему immutable языке нет возможности организовать двухсвязный список, да и вообще любую структуру с циклами.
Со вторым моментом я могу несколько ошибаться, потому что здесь многое зависит от принятых определений. Если сказать, что хаскель настолько крут, что позволяет сконструировать иммутабельную структуру с циклами, то наверное я не прав.
С точки зрения Garbage Collector — да. GC и не подозревает о том, что вы (как программист) не замечаете этой мутабельности.
Ну допустил человек в попыхах ошибку. Но её легко исправить.
Правда, это в очередной раз доказывает, что ни один язык не может спасти от всех ошибок.
Однако в хаскеле очень много мутабельности: все ленивые вычисления реализованы через мутабельность (с точки зрения GC).
Говорят, что с помощью ленивости в хаскеле возможно реализовать даже двухсвязные и циркулярные списки, что невозможно в языке с истинной иммутабельностью (например, в Erlang).