​В комментах под последним сообщением разгорелся небольшой срач, в котором меня явно приняли не за того.

Пользуясь случаем хочу прояснить несколько моментов:

1) on-premise bare metal, on-premise в облаке, managed database и serverless database это настолько разные с точки зрения эксплуатации вещи, что обсуждать что из них лучше без приземления в контекст не имеет никакого смысла. Даже любая опенсорсная база (mysql/postgresql), запущенная 4 разными способами будет иметь 4 разных набора свойств и тонких мест. А если еще начать сравнивать реализации у разных облачных провайдеров, можно совсем кукухой поехать :)

И тот, кто говорит, что можно легко развернуть базу на виртуалках и не переплачивать за RDS, скорее всего не делал этого для нагруженных проектов. Например, на AWS эта история довольно быстро упирается в лимиты iops и cpu credits.

2) Я не эксперт и не евангелист snowflake. (евангелист - Кент)
Мне категорически все равно будете ли вы использовать snowflake, redshift, bigquery или у вас много свободных сисадминов и вы сможете поднять кластер на clickhouse сами.
До весны 2020 я ничего не слышал про snowflake, но сейчас решил хайпануть и нажиться на кровавом ынтерпрайзе(и не только), который сплошь и рядом его использует.

Snowflake задуман интересно, реализован так себе, но невозможно отрицать то, что он дал волшебный пендель всей индустрии serverless db.

В нем встроены инструменты, которые для любой другой базы пришлось бы прибивать сбоку. Например, column-level security и etl.

Так же они попытались совместить в одной базе OLTP и OLAP, что тоже наложило свой отпечаток (микро-партишены, отсутствие вторичных индексов). А раздельное масштабирование compute и storage скорее всего станут key-feature многих новых баз.

И немного погрузившись в контекст, я понял почему ее выбирают крупные компании.

3) Clickhouse отличный продукт, мы использовали его в одном из проектов и после этого остались только положительные впечатления. Есть много тонкостей как в плоскости администрирования, так и в плоскости архитектуры, без знания которых использование принесет страдания.
Я очень надеюсь, что Althinity сделают из clickhouse удобную serverless платформу.

4) Утверждение, что в облаках сидят только стартапы, а серьезные ребята строят свои дц, пахнет нафталином :) Рассуждая об облаках, многие апеллируют к тому, что облака это дорого. Это справедливо, если считать железо "в лоб". Но правильный ответ зависит от разных вещей: cost management strategy - оптимизация capex или opex является приоритетом, стратегия масштабирования, найма и тд. Ведь железо надо покупать и обслуживать.

Подведу итог.
Существует много разных баз. Рассуждать кто кого заборет и воевать за какую-то одну не вижу никакого смысла. Мне хотелось бы делать инструменты для пользователей разных баз и зарабатывать на всех :)
Но т.к. ресурсы конечны, приходится держать нос по ветру, и бежать туда, где есть деньги.

​Пользуясь случаем, напомню всем желающим погреть руки на сноуфлейке (и на всем остальном) вместе с нами:
авторам любых бесплатных инструментов, сделанных на базе API parsers.dev и holistic.dev, которыми будут пользоваться платные подписчики сервисов, будет выплачиваться доля от инкама.

Монетизация будет запущена в начале 2021.
Подробнее я писал здесь.

​Наша постоянная рубрика "дед открывает современную российскую музыку".

Бодрый панк-рок в исполнении двух девушек: кис-кис. Узнал я про них из фита с Anacondas, у которых сегодня вышел клип. Напомнило группу фантастика вперемешку с нойзом и пошлой молли.

Пользуясь случаем порекомендую еще несколько забытых панкушников - кожаный олень, питоны 3000, все равно и, естественно, моя большая и давняя любовь - ландыши. Оно, конечно, совсем с другим саундом, но мы-то все знаем, что в русском роке главное текстА :)

Че происходит.jpg

Вообщем новость как-то прошла мимо меня.

Оказывается килобайт уже давно (с 1998 года!) не 1024 байт, а 1000.
А 1024 байт теперь называется Кибибайт.

Proof: https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D0%B1%D0%B8%D0%B1%D0%B0%D0%B9%D1%82

НГ (кродется). Желаю всем, чтобы без такой херни как в этом :) Как говорил дядя Витя, - watch yourself, be careful :)

Happy New Year’; DROP TABLE 2020;--

Зачем читать об итогах года каких-то левых людей из интернета?
Я это делаю с одной целью - осознать какая я ленивая жопа, и что за этот год я ни черта не сделал. Шейм он ми, так сказать.

А зачем подводить итоги года?
Порефлексировать и понять, что я все-таки не такая ленивая жопа как показалось в предыдущем пункте.

Поэтому давайте совместим 2 полезные активности в одну - я расскажу что за прошедший год у меня произошло, а вы почитаете.
Заодно расскажу новым подписчикам на что они подписались :)


Про меня
Меня зовут Антон и я трудоголик :)
В айти 20 с лишним лет. Интерпрайз 🖖, геймдев, финтех. Основная шиза - базы данных.

Поэтому если будут вопросы жизни смерти и всего такого по базам данных, обращайтесь. По своему профилю стараюсь помочь всем и практически всегда бесплатно :)

Собираю несколько подборок:
- халявные ресурсы для стартапов
- опенсорс SQL тулзы
- экзотические применения SQL


Про этот канал
Весь 2020 в этом канале я рассказывал о несовершенствах IT мира (зачем?) и делился своими соображениями о базах данных (большей частью).
Особую популярность приобрел после серии выпусков SQL-TIL :)
Серия не завершена и в 2021 обязательно будет продолжение.

Канал вырос до нереальных 1250+ подписчиков.
Отдельное спасибо всем авторам it-каналов, которые меня поддержали:
@oleg_log и @profunctor_io, @tech_b0lt_Genona, @count0_digest, @devfounder, @sysadmin_tools, @teamerlin, @dereference_pointer_there, @psauxww, @sec_devops, @repushko_channel, @isast, @java_memes, @datstuff, @ITmoonIT и другим сочувствующим.
Без вас бы ничего этого не было!


Про проекты
Вместе с отличной командой в 2020 мы запустили два сервиса holistic.dev (для DBA) и parsers.dev (для разрабов).

holistic.dev - статический анализатор SQL
Нужен для автоматического поиска проблем в запросах.
Запартнерились с несколькими крутыми компаниями, но пока официально партнерами можно называть только Яндекс.Облако. Надеюсь, что в первом квартале на сайте появится соответствующий раздел со всеми колабами :)

parsers.dev - ast парсеры и компиляторы
Нужен для создания тулинга для разрабов и не только.
В первом квартале надеемся запустить монетизацию и добавить партнерку

Подключайтесь!

Немного статистики:
65 репозиториев в рабочем гитхабе (на всех)
Мой вклад - почти 4k contributions, 125k sloc, wakatime репортит 1500 часов (что можно честно умножать на 2)

Языки: c, c++, flow, ts, немножко golang и java
Правила анализатора: 1400 в беклоге, 110 в проде
Тесты: около 3000
Расходы на облако: $60/month

Спасибо всем, кто участвует в этой затее и просто поддерживает :)


Про нетворкинг
Бесчисленное количество крутых и полезных людей было найдено в и через @ctodailychat и @siliconpravdachat


Инсайтс 2020
- Мир дата аналитики
- Snowflake
- Документалки
- Российские сериалы могут быть ничего
- В РФ нашлось только 4 смешных стендапера по версии меня
- В человеке много чего может болеть :(
- Если что-то решил - делай сейчас, "потом" может не быть
- Земля, сцк, маленькая и во всех странах происходит какая-то шляпа. Дайте мне другой глобус!


Регретс 2020
- Никуда не съездил
- Нигде не выступил
- Не купил барабаны
- Почти не занимался спортом
- Не прочитал целиком ни одной книжки
- Иностранными языками занимался на троечку, а осенью совсем забил
- Работал меньше, чем хотелось бы

Видимо, на фоне отсутствия впечатлений, ресторанов и путешествий понизились пороги включения тревожности и ОКР :)
Но совсем пропало желание это контролировать...
Вангую, что 2021-2022 будут жирными годами для психологов и проектов, которые выведут их онлайн.
Кто подался туда чуть раньше (bemeta.co от @zamesin, psyalter.ru от Бреслава), закроют все цели намного быстрее запланированного.

​Бонус трек - планы на 2021
- Похудеть
- Включить монетизацию на существующих проектах
- Запустить еще пару проектов, возможно даже с VC
- Подтянуть иняз
- Научиться в твитер, фб и линкед и завести там филиал сингулярности ru/en
- Читать хотя бы 1-2 книжки в квартал
- Завести распорядок дня
- Соблюдать распорядок дня
- Пережить ковид
- Все-таки похудеть :)
...
- Profit!

Наверное, я что-то интересное еще забыл, но мы же с вами не прощаемся - вспомню :)

Короче, надеюсь что у вас все гоуниг велл. Поднимаю за ваше психическое здоровье стакан валерьяны, а за физическое - гантель :)

Пожелаю вам тратить свое время только на любимые дела, т.к. жизнь коротка, а сингулярности, сцк, не будет :(

Увидимся, с праздниками!

В список опенсорсных SQL тулзин добавил разного на php, erlang, haskell.

Из интересного - автор ZomboDB делает депарсер постгревого AST обратно в SQL. Ни одного нормального опенсорсного решения нет.
Депарсер вроде как минорная фича, но усилий нужно приложить вагон. Респект автору!

Зачем нужен депарсер? Можно использовать для prettier’а, например. Автор делает это для своего фреймворка разработки экстеншенов под pg на rust.

В своих проектах пока приходится использовать один кривой-косой, который удалось найти. С радостью заменю его на другой :)

PS: собрал несколько парсеров для Cypher

​Добавили cypher в parsers.dev
Потому что а почему бы и нет? :)

Cypher это такой язык для запросов по графам. Работает в neo4j, redisgraph, sap hana и нескольких других.

PS: формат дерева у существующего парсера немного странный. Если будут заявки на более приличный вид - причешем.

Если по итогам года вам показалось, что трекать часы для самого себя это перебор, то взгляните на это:

https://samplesize.one/blog/posts/my_year_in_data/

меня тут попросили вакансию пофорсить.
мидл фулстек js в калифорнийский стартап.

до 300к.

если кому-то интересно, стучите, отфорваржу полное описание

Комрадс, меня попросили пофорсить еще одну вакансию. Даже две :)
CEO и CTO в немецкий стартап по AR:

www.manuarity.com

стучите, отфорваржу на человека

А давайте небольшой апдейт про holistic.dev

Как я уже говорил, мы в процессе налаживания официальных отношений со всеми основными облачными провайдерами в РФ. На данный момент с тремя из них можно быстро интегрироваться через FaaS (cloud functions - общее название aws lambda).
Для Yandex.Cloud, SberCloud и Selectel эти функции и инструкции по инсталляции можно взять в нашем гитхабе или на странице документации.

Чтобы не вышло как в последней новости, вот, держите:

https://news.1rj.ru/str/leftjoin/223

​Как можно проконтролировать, что после рефакторинга базы и/или запросов у вас ничего не сломается?

"Конечно, тестами!", - скажете вы.
Да. Но это не точно. Т.е. результаты не будут точными. Все сильно зависит от самих тестов. Причем даже больше от тестов с негативными сценариями.

Пример на это утверждение я приведу чуть ниже, а пока расскажу о том, что мы сделали инструмент для автоматического отслеживания изменений в типах результатов SQL запросов на основе parsers.dev!

Как он работает и кому нужен?

Надеюсь, что те, кто пишет запросы руками, хранит каждый запрос в отдельном файле. Если нет, рекомендую срочно начать это делать!

Итак, запросы у вас разложены по файлам, описание схемы тоже разложено по файлам с миграциями.
Актуальный код запушен в гит, изменения пока на локальной машине.
Запускаем скрипт с указанием расположения папок со схемой и запросами и получаем на выходе информацию о том, что изменилось с последнего пуша!

Отслеживаются:
- типы полей в результатах каждого запроса
- возможность каждого поля в ответе принимать значение NULL
- расхождения в источниках данных
- класс количества строк результата (NONE, ONE, ONE_OR_NONE, MANY, MANY_OR_NONE)

В описании пакета есть несколько примеров с гифками, поэтому предлагаю незамедлительно ознакомиться и попробовать! https://github.com/parsers-dev/sql-type-tracker

А пока пример на утверждение про тесты.

Давайте предположим, что у вас было как-то поле, у которого было ограничение NOT NULL. В процессе запиливания новой фичи стало понятно, что это ограничение нужно убрать.
Вы написали тесты для проверки поведения новой фичи с учетом этого самого возможного NULL.

А теперь несколько вопросов:
- как много запросов используют это поле для передачи его в приложение?
- как много запросов опираются на это поле при фильтрации и в джойнах?
- сломаются ли старые тесты без данного ограничения?

Правильные ответы - ХЗ, ХЗ и еще раз ХЗ.
Кажется, что самый важный из этих вопросов - последний. И ответ на него зависит от того как у вас устроены интеграционные тесты. Но в абсолютном большинстве случаев тесты ничего не покажут.

А чем нам это может грозить?
- в приложение попадут NULL в те места, где проверки на NULL нет
- джойны вместо 1 записи могут теперь выдавать 0 или наоборот много записей

В старых тестах все отлично - там мы эту ситуацию не ожидаем. По уму необходимо взять все существующие тесты и дописать на каждый кейс, который затрагивается этим NULL'ом, дополнительные тесты.
А какие кейсы затрагиваются этим NULL'ом?
И тут оказывается, что важными были все три вопроса...
И ответы появятся только на проде и только когда по новой фиче польются данные. В ночь с пятницы на субботу :)

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

Кстати, я надеюсь, что вы проверяете класс количества строк результата в приложении? :)

Давайте еще уточним, что этот NULL появился из-за нормализации данных, например. И там, где у нас данные тянулись из 1 таблицы, теперь они тянутся из двух. Нам нужно переписать Все запросы, где такое происходит.
Ок, не вопрос. Грепаем по имени таблицы все запросы и идем править.
И случайно в процессе копипасты, у нас в результат запроса попадает не то поле, которое нужно, а поле с таким же именем из другой таблицы. Тут id, там id... И типы одинаковые. И NULL'ов нет. Но данные теперь скомпрометированы!

Вот бы круто, если бы такое изменение можно было найти автоматом...

Ну вы поняли? https://github.com/parsers-dev/sql-type-tracker :)

Лайк, шер, пулл-реквест :)

PS: на higload2019 я делал доклад на эту тему.
PPS: смотреть необязательно :)