Если работать с внешними key/value хранилищами, которые не поддерживат транзакции, может понадобиться реализовывать их вручную. Да, для этого можно взять готовые средства, но и они в редких случаях будут давать сбои (в критической секции будет находиться два потока), только если не замкнут весь поток данных на себя. Если интересно — могу расписать подробнее.
Сильно утрирую: раньше в документацию по телевизорам входила и электросхема, сейчас там только инструкция по замене батареек в пульте, так вот, документация по ZooKeeper это электросхема, а по hazelcast — современная версия.
При разработке распределенных систем очень важно знать как система работает в нештатном режиме, при смерти нод, разрывах в сети и так далее, документация по ZooKeeper описывает это поведение, а бегло просматривая документацию по hazelcast я не смог этого найти.
Другой аспект это доверие, я верю в работоспособност систем в составе которых используется ZooKeeper, таких как Hadoop и HBase, а про использование hazelcast я ничего не знаю, может его используют в основном в качестве кеша и тогда его надежность не в приоритете у разработчиков.
Допустим, что у нас есть два клиента — A и B, и где-то в один момент времени A решил изменить данные, а B прочитать. Если B не знает, что данные изменились, то нет никакой разницы получит он старые данные или новые, но если он ожидает получить новые могут быть проблемы. Как B может узнать?
Через обработчик события, который он поставил (хорошо)
Через запись в другом znode о том, что в нужном данные изменились (хорошо)
Если A и B связались друг с другом напрямую (плохо)
В первом случае B получит правильные данные, из-за гарантий zk о том, что если клиенту пришло событие об изменении данных, то запрашивая данные он должен получить новую версию. Во-втором случае тоже будут новые данные из-за глобального порядка — если мы видим новые данные у одного znode, то мы гарантировано видим все изменения, которые были сделаны до него. В ситуации 3 у нас нет гарантий, поэтому, как поведет.
На самом деле, опыт показал, что такое поведение не большая проблема. Кстати в конфиге ZooKeeper можно указать максимальное время за которое должна происходить синхронизация узлами кластера и лидером (syncLimit).
От статьи веет пафосом, что еще больше раздражает при наличии фактических ошибок.
Так, например, поступила Microsoft при разработке платформы ASP.NET – скрипты для браузера могут быть написаны на любом языке платформы .NET (например, на C#) и затем автоматически преобразованы в соответствующий код на JavaScript
Ms так не поступала так, как такой функциональности в asp.net нет.
Первое, о чем следует помнить – разработчики Mono будут всегда на шаг позади Microsoft, так как они начинают реализовывать уже выпущенные библиотеки и стандарты.
Не стоит проводить равенство между mono и .net, они пересекающиеся технологии, но не равные. где-то mono задерживается от ms, где-то заметно впереди (managed компилятор от ms выпущен только в прошлом году, а от mono точно был в 2009), а где то вобще не имеет аналогов — monotouch и monodroid. Кстати, на D можно писать приложения под android и iphone, существуют биндинги к gui?
В настоящее время все патенты на C#/CLI принадлежат Microsoft..
Вообще то на c# стандарт есть (Ecma (ECMA-334) и ISO (ISO/IEC 23270:2006)) в отличии от, например, Java. А D стандартизован?
P.S. Я не понимаю, как можно доверять технической статье, которая содержит фактические ошибки, про которые автор пишет «Если честно, не помню, где именно про это читал» это не гуматитарщина, не знаешь — не пиши.
Советую посмотреть на Nemerle.Peg — не видел лучшего средства для создания парсеров под .net. У самого проект, который могу поддерживать только из-за того, что в свое время выбрал peg в качестве инструмента для создания парсера.
Из особенностой можно отметить отсутствие деления на лексер и парсер, а так же то, что писать парсер приходиться на Nemerle.
Ага, нужно, но, мне кажется, что по умолчанию заворачивать более неудобно и опасно.
1. Неудобно.
Если исключение, которое ты ожидаешь поймать в catch завернуто, то нужно ловить все, которые могут его завернуть, разворачивать их (а тут может быть не один уровень вложенности) и проверять is'ом.
2. Опасно.
a) когда я передаю делегат, который может кинуть мое исключение, в библиотеку, по умолчанию, я не предполагаю, что библиотека может завернуть его, следовательно, мой catch не сработает и программа будет работать некорректно.
b) нужно перехватывать *все* исключения, которые могут завернуть мое, и знать как они заворачивают, а на этапе компиляции этой информации запросто может не быть.
Заворачивая исключение в другое мы теряем информацию, но не очевидно, что приобретаем. В чем опасность того, что летят низкоуровневые исключения? (Если вы про Java, то я говорю только про unchecked exception)
Спасибо, действительно, не очень понятно получилось.
Я внимательно на link-walking не смотрел, но интуитивно кажется, что при их использовании вместе с значением храняться ссылки на другие значения, поэтому операция достать пост вместе с комментариями будет выполняться не за один запрос, а за N, где N — число комментариев, понятно что все это будет происходить внутри кластера и по идеи быстрее, чем снаружи, но все равно, это не один запрос.
При всей чтении всей ленты да, нужно обходить все чанки, но обычно нужна только голова ленты, поэтому достаем последний чанк, смотрим на кол-во элементов там, если мало, то берем еще и предыдуший чанк и возвращаем элементы, а в гуи будет кнопка или автоскрол, который будет подгружать данные из следующего чанка. Получается, что мы можем получить около 100-200 элементов за два запроса при длинне чанка в 100 элементов.
Нет, это просто псевдокод, который иллюстрирует проблему. Я не хотел использовать везде java, потому что получалась портянка кода и нужно было определять контекст, без него не удалось бы скомпилить, а давать куски кода, которые не работают, но выглядят работающими мне не кажется правильным.
При разработке распределенных систем очень важно знать как система работает в нештатном режиме, при смерти нод, разрывах в сети и так далее, документация по ZooKeeper описывает это поведение, а бегло просматривая документацию по hazelcast я не смог этого найти.
Другой аспект это доверие, я верю в работоспособност систем в составе которых используется ZooKeeper, таких как Hadoop и HBase, а про использование hazelcast я ничего не знаю, может его используют в основном в качестве кеша и тогда его надежность не в приоритете у разработчиков.
Спасибо, но я уже нашел это в документации, а до того как нашел — игрался с ramfs.
Допустим, что у нас есть два клиента — A и B, и где-то в один момент времени A решил изменить данные, а B прочитать. Если B не знает, что данные изменились, то нет никакой разницы получит он старые данные или новые, но если он ожидает получить новые могут быть проблемы. Как B может узнать?
В первом случае B получит правильные данные, из-за гарантий zk о том, что если клиенту пришло событие об изменении данных, то запрашивая данные он должен получить новую версию. Во-втором случае тоже будут новые данные из-за глобального порядка — если мы видим новые данные у одного znode, то мы гарантировано видим все изменения, которые были сделаны до него. В ситуации 3 у нас нет гарантий, поэтому, как поведет.
На самом деле, опыт показал, что такое поведение не большая проблема. Кстати в конфиге ZooKeeper можно указать максимальное время за которое должна происходить синхронизация узлами кластера и лидером (syncLimit).
Ms так не поступала так, как такой функциональности в asp.net нет.
Не стоит проводить равенство между mono и .net, они пересекающиеся технологии, но не равные. где-то mono задерживается от ms, где-то заметно впереди (managed компилятор от ms выпущен только в прошлом году, а от mono точно был в 2009), а где то вобще не имеет аналогов — monotouch и monodroid. Кстати, на D можно писать приложения под android и iphone, существуют биндинги к gui?
Вообще то на c# стандарт есть (Ecma (ECMA-334) и ISO (ISO/IEC 23270:2006)) в отличии от, например, Java. А D стандартизован?
P.S. Я не понимаю, как можно доверять технической статье, которая содержит фактические ошибки, про которые автор пишет «Если честно, не помню, где именно про это читал» это не гуматитарщина, не знаешь — не пиши.
Из особенностой можно отметить отсутствие деления на лексер и парсер, а так же то, что писать парсер приходиться на Nemerle.
1. Неудобно.
Если исключение, которое ты ожидаешь поймать в catch завернуто, то нужно ловить все, которые могут его завернуть, разворачивать их (а тут может быть не один уровень вложенности) и проверять is'ом.
2. Опасно.
a) когда я передаю делегат, который может кинуть мое исключение, в библиотеку, по умолчанию, я не предполагаю, что библиотека может завернуть его, следовательно, мой catch не сработает и программа будет работать некорректно.
b) нужно перехватывать *все* исключения, которые могут завернуть мое, и знать как они заворачивают, а на этапе компиляции этой информации запросто может не быть.
Радоваться, такие задачи встречаются редко…
Я внимательно на link-walking не смотрел, но интуитивно кажется, что при их использовании вместе с значением храняться ссылки на другие значения, поэтому операция достать пост вместе с комментариями будет выполняться не за один запрос, а за N, где N — число комментариев, понятно что все это будет происходить внутри кластера и по идеи быстрее, чем снаружи, но все равно, это не один запрос.
При всей чтении всей ленты да, нужно обходить все чанки, но обычно нужна только голова ленты, поэтому достаем последний чанк, смотрим на кол-во элементов там, если мало, то берем еще и предыдуший чанк и возвращаем элементы, а в гуи будет кнопка или автоскрол, который будет подгружать данные из следующего чанка. Получается, что мы можем получить около 100-200 элементов за два запроса при длинне чанка в 100 элементов.
Нет, это просто псевдокод, который иллюстрирует проблему. Я не хотел использовать везде java, потому что получалась портянка кода и нужно было определять контекст, без него не удалось бы скомпилить, а давать куски кода, которые не работают, но выглядят работающими мне не кажется правильным.