@lab:~$ cat smth/news
Итак, малютки, надо бы тишину разбавить. По новостям у нас следующее.
Queen(update!)
- Библиотека для миграций претерпела сильные изменения: развернулся на 180 градусов и полностью отказался от поддержки NoSQL-баз данных, ибо слишком много усложнений, которые могут привести к ухудшению DX как для самих NoSQL-баз, так и для SQL.
- Возникли небольшие проблемы с YDB, но думаю, в скором времени добавлю и её поддержку, ибо продукт, конечно, супер мощный и удобный.
- Добавил википедию для библиотеки:
Чтобы понять общее направление, в котором в будущем пойдёт разработка и на какой стул сядет королева, я отправил её на ревью нескольким командам разработки из пары бигтехов. Надеюсь получить хороший (по объёму) фидбек, чтобы сделать выводы и выбрать направление развития моей красавицы.
Фидбек от нескольких команд уже есть, и он достаточно противоречивый: одним нравится отказ от .sql, другим — не очень. Но буду ждать остальных, чтобы собрать полную картину.
Amber (new!)
Ой, а что это?
Append-only log/trace база данных. Когда наши продукты вырастают до 10 сервисов и больше, становится немного трудновато собирать со всех трейсы и логи. Мы, конечно, можем начать разворачивать наш дефолтный стек, а именно Elasticsearch / ClickHouse + Loki + Logstash — и он будет потрясно работать. Но для небольших и средних продуктов есть цена такого стека, а именно:
- Elasticsearch — Java heap, JVM tuning, mapping explosion, счёт за память и ещё куча проблем (ну и шизокачели с лицензиями тоже в копилку).
- ClickHouse хоть быстрее и компактнее для нас, но всё ещё SQL-СУБД с таблицами и схемами. Это круто работало бы, если бы логи были структурированными, но у нас они — полуструктурированные события с произвольными атрибутами, так что и тут мимо.
- Loki — наверное, самое близкое к тому, что мне было нужно, но индексирование, построенное на label, накладывает очень неприятные ограничения.
а еще FTS платный… кринж
Все это крутые и сильные инструменты, но для маленьких и средних продуктов они накладывают слишком большую операционную сложность, которая просто непропорциональна задаче.
Поэтому в нашем кейсе, когда у нас ~100 млн событий в день, я просто не вижу смысла в поднятии такого зоопарка. Хочется видеть сервис, который запускается одной командой, пишет на диск и отвечает на запросы быстрее, чем мы их пишем.
Про это и есть Amber. Через денёк-другой напишу большой пост про Amber с бенчмарками — может, кому-то будет интересно посмотреть, что там под капотом.
Что-то про пчёл?
Недавно я наблюдал за пчёлами на собственной пасеке и понял, что их поведение куда сложнее, чем кажется на первый взгляд. Колония медоносных пчёл — это не просто набор отдельных групп насекомых, а суперорганизм с жёстким разделением труда, развитой системой коммуникации и тонкой оптимизацией использования ресурсов.
Меня прям заинтересовало их социальное устройство: одни пчёлы занимаются внутренними работами в улье, другие — разведкой и сбором нектара, третьи — строительством и вентиляцией гнезда. Все эти роли координируются так, что семья функционирует как единое целое и в одиночку ни одна рабочая пчела выжить не может.
После этих наблюдений захотелось глубже погрузиться в биологию поведения пчёл, разобраться в ключевых поведенческих циклах — от фуражировки и танца разведчиц до строительства сотов и защиты гнезда — а затем перенести эти механизмы в наш с вами компьютерный мир , реализовав агентно-ориентированную симуляцию на гошке. Может даже подчерпну чего-нибудь у природы для реализации других своих проектов, кто знает...
Надеюсь пчёлы в симуляции не построят коммунизм xd