?

Log in

No account? Create an account

Заповедник репрессивной психиатрии

Entries by category: происшествия

Репликация таблицы БД с помощью очередей
metaclass
Я тут, как обычно, подумываю, как бы заменить прямое обращение к БД из сервисов на хождение мессаг по очередям и посетила меня такая мысль: можно ли с помощью очереди, гарантирующей доставку "один раз или больше" реплицировать одну таблицу в БД, если у нее есть естественный ключ?

Мне что-то мерещится, что такая таблица является вариантом CRDT (если я воще правильно понимаю, что это такое) и можно гарантировать, что изменения с одной стороны, попавшие в очередь, дойдут до второй стороны и содержимое таблиц в конце-концов сойдется.

В случае гибели одной из БД и восстановления ее из резервной копии на какой-то момент времени, состояние рассинхронизируется и придется из второй БД принудительно передавать все данные, чтобы дозаполнить первую, или же хранить в БД полный лог изменений (заполняемый триггерами, например) и передавать изменения, начиная с момента логического времени, который видела умершая БД на момент своего резервного копирования.

Для случая нескольких таблиц со связями/FK уже так просто не получается - нужно чтобы таблицы, между которыми есть связи, реплицировались в правильном порядке - невозможно создать запись, в которой есть ссылки на другие, раньше их и удалить запись, на которую есть ссылки из других, до них невозможно.

Обычно я делаю распределенную транзакцию с двухфазной фиксацией с двумя БД и передаю данные лога транзакций и изменений между БД, пока оно работает как положено, за исключением того, что это прибивает гвоздями решение к протоколу Firebird, в котором эти распределенные транзакции предусмотрены и, например, убрать прямое обращение к БД и гонять данные по http(s) между сервисами не получается. Было бы интересно, опять же, рассмотреть вариант репликации данных между разными СУБД.

Назойливость, как ключевая бизнес-практика в России
metaclass
Originally posted by alexdjachenko at Назойливость, как ключевая бизнес-практика в России
Подавляющее большинство людей и компаний, с которыми Вы столкнётесь в России, как двухглавые орлы: птицы гордые, но бессмысленные и без смачного пендаля будут только задумчиво кивать, переминаясь с ноги на ногу и гадить.

Ваш подчиненный принял задачу? Коллега обещал посмотреть документ к четвергу? Поставщик - привезти товар в среду?
И Вы им поверили?
Ха! Сюрприз отечественного бизнеса - ни к указанной дате, ни через неделю, ни через месяц ничего сделано не будет. Вообще ничего! Даже не начнут! Даже не вспомнят.

Единственный способ, сдвинуть дело с мертвой точки - задудонить "орлов" до такой степени, чтобы они даже во-сне беспокойно взрагивали и ворочились, потому что даже во-сне им должно сниться, как Вы им звоните и напоминаете.

Отбросьте в сторону свои сомнения и стеснительность. Вы просто делаете свою работу. И раздражаться этому могут только ленивые бездельники, которые не собираются исполнять данные обещания. Остальные все поймут и будут Вас уважать, как человека пунктуального и делового.

Встречи
Назначенная встреча не состоится, если сразу после договорённости о ней, вы не отправите всем участникам письмо со временем и местом. Еще одно - в понедельник утром той недели, на который запланирована встреча. В конце предыдущего дня необходимо обзвонить всех участников встречи и поинтересоваться, в силе ли договоренность. Еще раз - за 3 часа до встречи. Ну и за 5 минут до начала встречи необходимо позвонить всем, кого еще нет в условленном месте.

Доставки
Если у вас приняли заказ, это не значит, что его собираются доставить. И уж совсем не значит, что его собираются доставить в назначенный срок. Чтобы увеличить вероятность этого, необходимо напомнить звонком трижды: один раз - когда формируются маршруты на день доставки. Один раз - в самом начале дня доставки, когда еще не поздно вписать в маршрутный лист ваш адрес, который забыли вписать вчера, ну и еще раз звоните в конце интервала времени, когда вам обещали доставку и никто не приехал.

Коллеги
Если Вам от них что-то нужно - это всегда трудный случай. Особенно если в вашей компании не применяется таск-треккер. Без него вообще не жизнь.
Обязательно дублируйте все свои просьбы письменно, с указанием срочности и предельных сроков. В письме просите назвать точную дату, когда он пришлет результат. Критические сроки уменьшайте - чтобы когда они наступят, было время добиться от коллеги требуемого. Даже не надейстесь, что коллега начнет действовать раньше дедлайна.
Как только наступила обещанная дата - не откладывая ни на секунду пишите письмо. Если на него не среагировали - не мешкая звоните или напоминайте лично. Просите назвать новую дату. Если дату так и не назвали - напоминайте каждые несколько часов, минимум - ежедневно.
Когда наступит дедлайн, пересылайте письмо, где Ваш коллега назвал дату, получателем ставьте коллегу, в копию - своего и его руководителя. В письме описывайте, как ужасно и плохо всем стало от того, что еще ничего не выполнено.

Партнеры и клиенты
Я Вам сочувствую, правда, мне Вас искренне жаль, очень очень. Потому что если у вас нет под рукой вентиля, перекрывающего нужному человеку кислород, или кнопки активации штырей в сиденье его стула - ситуация почти безнадёжна.
Ругаться в этом случае никак нельзя, звоните на пределе вежливости. Описывайте, как вам плохо от того, что вы еще не получили никакого ответа, как Вас ругает ваш руководитель/клиенты/поставщики, какие кары Вам грозят. Вашему контрагенту это всё абсолютно неинтересно, поэтому рассказывайте как можно дольше и подробнее.
Всеми правдами или неправдами просите назвать дату. Если дату не назвали - звоните не реже раза в день. Старайтесь беседовать как можно дольше, спрашивайте, чем можете помочь, живопишите новости совместного проекта. Контрагенту должно быть быстрее и проще один раз выполнить требуемое, чем ежедневно с Вами беседовать. Главное - не бойтесь надоесть, если ТАКОЙ контрагент предпочтет отказаться от дальнейшего сотрудничества - он этим окажет Вам услугу.


А штыри в стуле были бы решением!

scala spray slick restful ад заборы коровники коворкинги хипстеры
metaclass
В целях недопущения упрощения жизни, а так же чтобы псить, при необходимости, со знанием дела, осиливаю скалу.
Причем начал практически с конца - клепаю RESTful сервис на основе spray с всякими json-маршалингами внутри через имплициты и прочую адову содомию.
При достаточном количестве type-level магии оно выглядит, конечно, так же просто, как какое-нибудь руби, или как лиспы без скобок и с инфиксной записью, но внутренняя сложность, по-моему, зашкаливает. "Импортируй себе немножечко имплиситов и получи на халяву сериализаторы в json для всего", "Оберни маршруты в директивы логгера" и прочее такое.

Сборку завел, сначала через sbt (простой способ), потом импортировал в IDEA (условно простой) и потом стырил у jdevelop конфигурацию для мавена (нормальный способ). Воедино надо это как-то свести, чтобы не редактировать при добавлении новых зависимостей все вручную. Плюс еще импорт sbt в IDEA выглядит как ад и смерть.

Завести то я это чюдо заведу, но вот что с ним дальше делать, не совсем понятно. На данный момент картина выглядит так: Clojure проще, но скобки и стектрейсы компилятора отпугнут новых пользователей, Scala дико сложнее, но поначалу она выглядит как "почти жаба", обработка ошибок более читабельна и есть шансы, что в эту западню попадутся и желающие новеньких языков и любители сойти с ума на почве вычислений на типах.
Tags: ,