Базы данных *

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

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

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

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

Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.

Что представляет собой книга

Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.

Её можно использовать как:

• офлайн-версию курса для повторения материала;

• удобный конспект при выполнении практических заданий;

• справочник для быстрого повторения основных конструкций SQL.

Если вы уже проходите курс, книга поможет быстрее находить нужную информацию и возвращаться к темам, которые хочется повторить.

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

• студентов IT-специальностей;

• начинающих разработчиков;

• будущих аналитиков данных;

• тестировщиков;

• всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

Чтобы скачать последнюю актуальную версию, перейдите в раздел Releases, где всегда доступен самый свежий выпуск книги. 

https://github.com/Awilum/sql-introduction/releases

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

В предыдущих видео я рассказывал о том, как Digital Q.DataBase воспроизводит функциональность Microsoft SQL Server, позволяя переносить приложения без переписывания прикладной бизнес-логики. Мой коллега Илья Лебедев также подробно рассказал о возможностях воспроизведения функциональности Oracle и подходах к миграции Oracle-приложений.

В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.

Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.

В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.

Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.

В этом видео вы узнаете:

🔹 почему импортозамещение крупных банковских систем требует особого подхода;
🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server;
🔹 почему стандартного PostgreSQL оказалось недостаточно;
🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase;
🔹 как удалось сохранить существующий T-SQL-код без его переписывания;
🔹 какие доработки были выполнены для повышения производительности;
🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях;
🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.

Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.

Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   
🔹 MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.

В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.

Но полиглотность Digital Q.DataBase этим не ограничивается.

Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.

В этом выступлении обсуждаются:

🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код.
🔹 Почему SQL- и PL/SQL-код может выполняться без изменений.
🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике.
🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC.
🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет.
🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.

В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.

Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   
🔹 MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Новости мира Datalakehouse - DWH: на 26.06.26

"гонка сместилась к ИИ-агентам"

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

Сначала про слово, которое будет дальше. Lakehouse - это подход, когда вся аналитика компании живёт в одном общем хранилище поверх дешёвых файлов, без отдельной дорогой базы под отчёты. Дальше речь о том, что с этим подходом случилось за полгода.

Databricks (их большая конференция прошла 16 июня). Показали новый движок Lakehouse//RT - он обещает выдавать аналитику почти мгновенно прямо из общего хранилища, без отдельной быстрой базы под витрины. Пока это ранняя версия и работает только на чтение, то есть данные через него можно читать, но не записывать. Второй анонс - способ держать «живые» рабочие данные и аналитику в одном месте, без постоянной перекачки между системами (обычно компании гоняют данные туда-сюда ночными выгрузками). Третий, и самый показательный - набор инструментов, чтобы пускать к данным ИИ-агентов: объяснять программе смысл данных и контролировать, куда ей можно лезть, а куда нет.

ClickHouse (своя конференция 27 мая). Это очень быстрая база для аналитики. Они запустили собственную управляемую версию Postgres - популярной базы, на которой работают тысячи приложений, - и научили её мгновенно отдавать все изменения в аналитику, без задержек. Плюс добавили ИИ-агентов поверх данных, построенных на Claude. По деньгам у них всё хорошо: годовая выручка за год утроилась и перевалила за 250 миллионов долларов.

Snowflake. Открыли свой каталог данных Polaris - это, грубо говоря, общее оглавление всех таблиц, по которому разные программы понимают, где что лежит. Раньше он был только их, теперь его передали в открытый фонд Apache, чтобы пользоваться им могли любые инструменты. А популярный открытый формат таблиц Iceberg дорос до новой версии и научился хранить более сложные данные.

SAP покупает компанию Dremio (сделка ещё не закрыта). Крупный вендор корпоративного софта докупает технологию, чтобы собрать собственное хранилище нового типа под ИИ. Это часть общего движения: рынок сходится вокруг одного открытого формата данных - того самого Iceberg.

DuckLake дорос до версии 1.0. Маленький и нарочно простой проект: он хранит оглавление данных в обычной знакомой базе (Postgres), а не в куче разрозненных служебных файлов, как делают старшие конкуренты. Меньше магии - проще обслуживать.

Если совсем коротко: скорость никуда не делась, её даже больше. Но она перестала быть главным козырем и стала фундаментом. Поверх неё все теперь строят слой управления ИИ-агентами - как объяснить программе смысл данных и как не пустить её туда, куда нельзя. По сути это ровно то, чем администраторы баз данных занимаются уже много лет, просто теперь у этого модные названия.

Дальше разберу каждый анонс по отдельности. Ждите продолжения.

Подъехало продолжение:

Databricks (их большая конференция прошла 16 июня) - ссылка на подробный разбор

В этом докладе я (Жуйков Андрей, амбассадор компании «Диасофт») рассказываю о подходе Digital Q.DataBase к импортозамещению зарубежных СУБД и миграции корпоративных систем без переписывания прикладного кода.  

В видео рассмотрены: 

🔹 архитектура и возможности Digital Q.DataBase; 
🔹 технология Polyglot и поддержка нескольких SQL-диалектов в одной СУБД; 
🔹 совместимость с Microsoft SQL Server и Oracle; 
🔹 исполнение T-SQL и PL/SQL без изменения бизнес-логики приложений; 
🔹 поддержка протокола TDS и работа со стандартными драйверами Microsoft; 
🔹 миграция 1С с Microsoft SQL Server на Digital Q.DataBase; 
🔹 демонстрация работы через DBeaver, SQL Server Management Studio и Python; 
🔹 поддержка Service Broker, Reporting Services и CLR-сборок; 
🔹 примеры реальных проектов и опыт внедрения у заказчиков.  

Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.

Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.   

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   

Подписывайтесь на наши сообщества, чтобы получать новости, технические материалы и информацию о новых вебинарах.  

#digitalqdatabase  #Diasoft #PostgreSQL #MicrosoftSQLServer #Oracle #Импортозамещение #СУБД #Database #TSQL #PLSQL #1С #DataBaseMigration #жуйковандрей

Бесплатный курс «SQL Введение» для тех, кто начинает изучать базы данных

Всем Привет!

Недавно я опубликовал новый бесплатный курс «SQL Введение» на платформе Stepik и хочу рассказать о нём сообществу.

https://stepik.org/course/290855

За время преподавания SQL я заметил одну проблему: многие начинающие сталкиваются со слишком сложными объяснениями уже на первых этапах обучения. Вместо понимания базовых принципов работы с данными люди сразу погружаются в большое количество терминов, теории и особенностей конкретных СУБД.

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

Курс ориентирован на тех, кто:

• никогда раньше не работал с базами данных;

• не писал SQL-запросы;

• хочет понять основы SQL перед дальнейшим обучением;

• учится на IT-специальности;

• рассматривает карьеру разработчика, аналитика данных, тестировщика или бизнес-аналитика.

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

Что изучается в курсе

В рамках курса рассматриваются базовые принципы работы реляционных баз данных и основные конструкции SQL.

В процессе обучения вы разберётесь с основами SQL и научитесь:

• понимать, как устроены таблицы и данные

• писать первые SQL-запросы

• выбирать столбцы из таблицы

• фильтровать данные

• использовать операторы сравнения

• формировать простые выборки

Материал построен по принципу «от простого к сложному». Каждый новый урок опирается на предыдущий, поэтому курс подходит даже тем, кто начинает изучение SQL с нуля.

Курс включает:

• теоретические уроки;

• тестовые задания для проверки понимания материала;

• практические упражнения с SQL-запросами.

Главная цель курса — помочь новичку разобраться в фундаментальных принципах работы с данными и научиться уверенно писать свои первые SQL-запросы.

Почему курс бесплатный

Я хотел создать качественную точку входа в SQL, доступную каждому. Многие люди только начинают свой путь в IT и ещё не готовы покупать большие программы обучения. Бесплатный вводный курс позволяет понять основы и решить, интересно ли двигаться дальше в этом направлении.

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

Начать обучение можно здесь:

https://stepik.org/course/290855

30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.

В программе:

• эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;

• новые возможности платформы и сценарии их применения;

• устройство и особенности распределенной СУБД Tantor Polar;

• организация вычислительных ресурсов и ресурсов хранения;

• инструменты управления и мониторинга.

Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.

Эксперты мероприятия:

• Вадим Яценко, генеральный директор «Тантор Лабс»

• Сергей Серегин, руководитель технического пресейл «Тантор Лабс».

Когда: 30 июня, начало в 11:00 (онлайн)

Зарегистрироваться

TXORDER-01: 7 тестов прошли, 8-й нашёл баг

Как domain state в одном тесте сделал видимым баг в порядке операций внутри транзакции — и что это говорит о том, что на самом деле проверяют “зелёные тесты”

7 тестов прошли.

8-й нашёл баг в production flow.

Не потому что был написан лучше. Потому что запустился с другим начальным состоянием системы.

Операция и транзакция

PATCH /reschedule — перенос appointment пациента на другой слот. Атомарная транзакция: освободить старый слот, занять новый, переместить запись. Плюс promoteFromWaitlist: если на освобождённом слоте есть очередь, первый из неё автоматически получает appointment.

Порядок операций в транзакции:

1. free_old_slot(slot1)

2. promoteFromWaitlist(slot1)

3. book_new_slot(slot2)

4. move_appointment(appointment → slot2)

Почему 7 тестов ничего не нашли

Тесты 1–7 проверяли стандартные сценарии: перенести pending, перенести confirmed, попытаться перенести на занятый слот. Ни в одном из них не было пациента в вейтлисте.promoteFromWaitlist в каждом тесте — no-op. Очередь пуста, функция вызывалась, ничего не делала, возвращала успех. Это важная деталь: функция не падала. Она просто не активировалась. Порядок операций вокруг неё не имел значения — потому что одна из операций ничего не делала.

7 зелёных тестов говорили: reschedule работает корректно. На самом деле они говорили: reschedule работает корректно когда вейтлист пуст.

Что нашёл 8-й тест

Пациент 2 встал в очередь на slot1. Пациент 1 запустил reschedule на slot2.

Ответ: 409 SLOT_IN_USE.

Слот был свободен. Пациент имел право переноса. Транзакция откатилась.

Механизм

1. free_old_slot(slot1) ← слот доступен

2. promoteFromWaitlist(slot1) ← пациент 2 получил pending на slot1

3. book_new_slot(slot2)

4. move_appointment → slot2 ← appointment пациента 1 ещё на slot1

После шага 2 на slot1 два active appointment одновременно: пациента 1 (ещё не переехал) и пациента 2 (только что из промоушна). UNIQUE constraint one_active_per_slot. Откат. 409.

Транзакция дисциплинированно выполняла логически неверную последовательность — и откатывалась на constraint.

Фикс

Appointment должен покинуть slot1 до того как promote вставляет нового пациента:

1. book_new_slot(slot2)

2. move_appointment → slot2

3. free_old_slot(slot1)

4. promoteFromWaitlist(slot1)

8-й тест прошёл

Что означают 7 зелёных тестов

Тест проверяет поведение системы при конкретном начальном состоянии. Если в наборе тестов нет нужного domain state — класс ошибок невидим, сколько бы тестов ни прошло.

В данном случае критическое условие — пациент в вейтлисте — отсутствовало во всех семи тестах. promoteFromWaitlist` был no-op в каждом из них. Баг в порядке операций существовал с момента написания — просто не было состояния которое его активировало.

Атомарность транзакции гарантирует: либо все операции выполнятся, либо ни одна. Она не гарантирует что операции написаны в правильном порядке. Это разные гарантии — и мы путали их семь тестов подряд.

Скрытое предположение “Я решилf что если транзакция атомарна — порядок операций внутри неё можно не тестировать. На самом деле транзакция защищает от частичных обновлений, но не от логически неверного порядка внутри.”

Код проекта: GitHub

Из серии “Тихие отказы в тест-автоматизации” Разборы таких кейсов — в Telegram-канале Тесты как система

Всем привет, нужны рекомендации и советы по следующим вопросам:

1. Порекомендуйте бесплатные ресурсы для подготовки к собеседованиям по аналитике.

2. Если найдётся кто-то, кто работал над галлюцинациями и достоверностm. информации, сгенерированной LLM, поделитесь опытом.

В предыдущих сериях был реализован простейший движок на основе HashMap, в которой сохраняются данные key -> value, и в принципе была открыта дорога для написания сервера и клиента для тестов. Но я решил добавить в Space работу с распределенными (XA) транзакциями.

Наличие такого механизма обязательно приведет к деградации производительности. Закономерно возникает вопрос: для чего это было сделано? Memifydb - это распределенная БД и она должна обеспечивать конкурентный доступ к данным обеспечивая их целостность. Что проку если она будет работать быстро, но её содержимое будет - хаос? Ведь деже при создании простого приложения для обработки данных в нескольких потоках используется synchronized в java (и пр. механизмы синхронизации).

Второй момент состоит в том что я всегда работал с транзакциями на стороне клиента, т.е. работал с менеджером транзакции (TransactionManager). Теперь же я писал сервис и пришлось иметь место с менеджером ресурсов (XAResource), что тоже интересно (не забываем что проект модельный и исследовательский).

Итак, транзакционность добавил, пока что на уровне RAM без сохранения данных в долговременную помять для отката/восстановления. Следующий шаг это написание самого сервера, который будет управлять Space’ами и обработкой клиентских запросов.

👉 Telegram: https://t.me/memifydb 👉 GitHub: https://github.com/yourname/memifydb

Демонстрация low-code коннектора к «1С:Шине» от «Денвик»

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Пока «Фирма 1С» не выпустила поддержку «1С:Шины» в БСП, мы тестируем партнерские решения. Недавно в статье на Хабре я пригласил к сотрудничеству компании, у которых уже есть готовый коннектор, и первым откликнулся «Денвик».

«Денвик» — российский продукт для автоматизированной выгрузки данных из 1С во внешние аналитические базы и BI-системы. Кроме экстрактора есть инжектор — инструмент обратной загрузки данных в 1С. Оба инструмента имеют low-code интерфейсы. За счет этого типовые сценарии выгрузки из 1С и загрузки в 1С можно настраивать через интерфейс, без привлечения разработчика.

Можно ли экстрактор и инжектор использовать в качестве коннектора к «1С:Шине»? Да, можно. На вебинаре в этот четверг вместе с product owner «Денвик» Степаном Пыстиным покажем, какие задачи решаются с помощью инструментов «Денвика».

Спикеры:
— Сергей Скирдин, технический директор «Белого кода»
— Степан Пыстин, product owner «Денвик»

📅 Дата: 14 мая
🕛 Время: 12:00 МСК
📍 Формат: онлайн

➕ Для участников вебинара команда «Денвика» предоставит бесплатный тестовый доступ.

Регистрируйтесь на вебинар и приходите!

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

Другую забавную байку в комментах поведал аноним с одноразовым аккаунтом. Примерно десять лет назад товарищ анонима перешёл на работу в некий стартап в качестве технического директора. Дела у компании шли отлично, бизнес быстро рос, в команде было порядка 200 разработчиков.

В первую неделю новый техдир обнаружил, что в стартапе заведён специальный микросервис для генерации UUID. Все остальные команды были проинструктированы передавать запросы на генерацию «безопасных» UUID именно в этот сервис. Новый сотрудник начал разбираться и обнаружил, что сервис — это запросы в отдельную базу данных, которая и хранила все до этого выданные UUID.

Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу и думаем о данных.

Взлетаем, создал репозиторий под проект https://github.com/mathter/memifydb.git

План

План общий такой:

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

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

Сделано

• Данные клиента будут храниться в space’ах - это будет аналог таблиц в БД. Для начала будет только key-value space что бы можно было подумать уже сейчас о WAL клиенской библиотеке для java и сетевом уровне в целом и конечно же о транзакциях.

• Тестовая реализация WAL, которая в проекте будет называться Log.

Run.

Как я запускал российское зеркало для SQL-песочниц: гибридное облако и блокировки Composer

Привет, Хабр! Меня зовут Слава, я развиваю SQL-платформы sqltest.online и sqlize.online для бесплатной тренировки запросов на реальных СУБД (PostgreSQL, Oracle, MariaDB 12.3, MS SQL 2025).

Зачем понадобилось зеркало?

От 30% моей аудитории из РФ стали приходить сообщения: «Сайт открывается только через VPN».

Переносить бэкенд целиком - дорого, сервер завязан на тяжелые СУБД в Docker. Поэтому я выбрал гибридную модель: поднять фронтенд в зоне .ru, оставив бэкенд в Германии.

Архитектура: Фронт в РФ, мозг в Германии

Фронтенд: PHP без фреймворков

Нативный PHP, HTML и JS. Меньше зависимостей - проще деплой. Для RU-зеркала я выбрал SpaceWeb*, где есть отличные бюджетные тарифы и классная поддержка.

sqltest-online.ru (SpaceWeb, РФ)
├── PHP (без фреймворков) + HTML/JS
└── Минимум зависимостей

Бэкенд: Docker Compose

Мощный сервер в Германии у Contabo*, где в контейнерах крутятся MySQL, PostgreSQL, ClickHouse и другие базы. Серьезные СУБД требуют ресурсов, так что всё живет на одной полноценной машине.

Как они общаются?

Пользователь отправляет запрос -> браузер делает AJAX-вызов к .ru серверу -> фронт делает HTTP-запрос к бэкенду в Германии (server-to-server) -> бэкенд выполняет SQL и возвращает результат.

Плюсы схемы:

• CORS не нужен: браузер общается только со своим доменом.

• Бэкенд закрыт: принимает запросы только от white-list IP.

• Задержка минимальна: интерфейс грузится из РФ, тяжелые запросы идут по быстрому каналу серверов.

Резервного бэкенда нет - проект бесплатный, на второй сервер пока нет бюджета. Если падает Германия, ложится всё.

Проблемы деплоя: Composer «ушел в отказ»

С git pull всё прошло гладко, но установка зависимостей зависла намертво.

Проблема: Composer не мог достучаться до packagist.org. Просто бесконечный таймаут, вызванный нестабильностью сетевых маршрутов.

Решение: Поддержка SpaceWeb не стала отписываться «проблема на вашей стороне», а сразу дала адрес HTTP-прокси.

Дело одной команды:

export HTTPS_PROXY=http://proxy.host:port
composer install

(Для Windows: set HTTPS_PROXY=...)

Мораль: При деплое на российские площадки проверяйте доступность packagist.org (curl -v https://packagist.org). Если висит - просите прокси у хостера, не тратьте время на Composer.

Итоги

Зеркало sqltest-online.ru работает. Гибридная схема спасает: пользователи получают быстрый интерфейс без VPN, а запросы улетают на проверенный бэкенд.

Я верю, что образование должно быть доступным. Если для практики SQL нужно включать VPN и ждать по 10 секунд - человек не будет учиться. Зеркало .ru - мой способ сказать: «Продолжайте практиковаться».

А как вы деплоите зависимости на RU-площадки? Используете прокси, зеркала или есть решения изящнее?

* P.S. Ссылки на SpaceWeb и Contabo в статье - реферальные. Сервисами пользуюсь сам и смело рекомендую, а бонусы пойдут на оплату серверов проекта.

Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок

Самостоятельное администрирование баз данных может превратиться в рутину: постоянные обновления, бэкапы, мониторинг и работа с нагрузкой. С ростом проекта стандартных настроек уже не хватает, а риск просадок и простоев из-за ошибок в конфигурации становится выше.

Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.

О чем будем говорить:

• сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;

• разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;

• обсудим, как архитектура Master/Replica повышает отказоустойчивость приложения.

После теории будет насыщенное демо, на котором покажем, как добавить в сервис поддержку нескольких реплик и разгрузить базу на чтении. Затем проведем нагрузочное тестирование и сравним показатели до и после оптимизации. Еще покажем, как организовать резервное копирование, разделить трафик на чтение и запись и повысить отказоустойчивость приложения.

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

📅 Встречаемся во вторник, 28 апреля, в 11:00 мск

Зарегистрироваться на вебинар

Терабайты данных из Teradata в Trino — эффективный способ передачи

В Data Ocean Nova был добавлен новый Trino Teradata Connector, который упрощает ad hoc-доступ к данным из Teradata и позволяет выгружать терабайты данных без кратного роста нагрузки на источник. Коллеги в новой статье объясняют, почему привычная параллельная выгрузка через несколько запросов плохо масштабируется, и показывают более правильный подход: распределять чтение по AMP’ам Teradata так, чтобы каждый из них читался только один раз.

Авторы разбирают архитектуру Teradata, типичные ошибки при многопоточном извлечении данных и принцип работы федеративного доступа через Trino. Отдельно показывают, как коннектор в Data Ocean Nova помогает организовать эффективную многопоточную передачу данных и использовать push-down для фильтрации, агрегаций и join’ов, когда это действительно уменьшает объем выборки.

Как всегда, в статье много полезных советов. Читайте и комментируйте!

🔌Форматы обмена и хранения данных

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу я написал, что собираюсь сделать исследовательский проект по in-memory базам данных  и имя ему MemifyDB. Так же выбрал направление движения: это key-value хранилище, которое потом доработаю до документо-ориентированной системы.

Теперь ключевой вопрос: как клиенты будут с ней общаться?

Протокол обмена — это мост между сервером и клиентом. От его дизайна зависит скорость, удобство и даже то, какие фичи мы сможем реализовать.

Human readable (JSON, XML and etc.)

В современных системах активно используется как для транспорта так и для хранения текстовый формат данных, а точнее json и его вариации. У этого подхода есть несколько несомненных плюсов, например:

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

• Гибкость: строкой можно закодировать что угодно — число, JSON, бинарные данные.

Но у этого подхода есть обратная сторона:

• ❌ Нет нативной поддержки типов: Клиент сам должен сериализовать/десериализовать.

• ❌ Оверхед на парсинг: Каждый раз нужно преобразовывать “42” в число и обратно.

• ❌ Неэффективное использование памяти: Число 123456 занимает 6 байт как строка, хотя в бинарном виде — 4 или 8.

• ❌ Невозможность частичного обновления сложных структур: Чтобы изменить одно поле в JSON-объекте, приходится переписывать весь объект (можно конечно поспорить).

## 🎯 Наш подход: типизированные данные с рождения В MemifyDB мы пойдём другим путём.
Мы будем хранить данные в памяти в типизированном виде: строки, числа, списки, хеши, документы — каждый тип со своим внутренним представлением.

И протокол обмена с клиентом должен это отражать.
Мы не хотим, чтобы клиент упаковывал число в строку только потому, что так проще.
Мы хотим передавать по сети те же бинарные структуры, которые лежат в памяти.

Это даст:

1. Типизированность Формат должен явно различать типы данных: строки, числа (разной разрядности), булевы значения, null, массивы, объекты (документы).
   Это позволит серверу правильно интерпретировать данные без дополнительных метаданных.

2. Компактность Формат не должен раздувать данные. Число 42 должно занимать 8 байт (или 4, если это int32), а не 2 символа ASCII.

3. Быстрая навигация Мы должны иметь возможность быстро «прыгнуть» к определённому полю документа без полного парсинга.
   Это важно для частичных обновлений и запросов.

4. Потоковость Формат должен допускать частичную отправку/приём, чтобы можно было обрабатывать большие документы по частям.

5. Самодостаточность Данные должны содержать всю информацию для интерпретации, но при этом не дублировать имена полей без необходимости (как в JSON).

🔍 Что дальше?

Существуют несколько бинарных: CBOR, BSON, FlatBuffer и пр. Если у вас есть опыт работы с этим форматами, пишите в комментариях какие у них есть плюсы, минусы и подводные камни.

🧠 MemifyDB: прежде всего — видение (vision).

Прежде чем погружаться в код, нужно чётко ответить на вопрос: а что именно мы строим?
Этот пост — не про хардкорный кодинг, а про так называемое видение системы (system vision).
Мы разберём, какие вообще бывают in-memory базы данных, чем они отличаются и почему наш путь будет таким: key-value → документная БД.

Поехали!

📚 Типы in-memory баз данных

1. Key-Value хранилища

Самый простой и быстрый вид. Данные хранятся как пары «ключ — значение», где значение — обычно строка, число или бинарный объект.

• Примеры: Redis, Memcached, DragonflyDB.

• Сценарии: кэширование, сессии пользователей, счётчики, очереди задач.

• Плюсы: максимальная скорость, минимальный оверхед, простота масштабирования (шардирование по ключу).

• Минусы: ограниченная модель данных — нет сложных запросов, только операции по ключу.

2. Документо-ориентированные БД

Значение — структурированный документ (JSON, BSON, XML). Внутри документа можно индексировать поля и выполнять запросы по содержимому.

• Примеры: MongoDB (in-memory storage engine), Couchbase.

• Сценарии: хранение сложных объектов (профили, каталоги), где важна гибкость схемы.

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

• Минусы: чуть более высокий оверхед по сравнению с key-value (парсинг, индексация).

3. Колоночные (Columnar) in-memory БД

Данные хранятся не по строкам, а по колонкам. Это даёт огромное преимущество при аналитических запросах (суммы, средние, группировки).

• Примеры: SAP HANA, MemSQL (SingleStore) в колоночном режиме, Apache Arrow (формат, но не БД).

• Сценарии: аналитика реального времени, отчёты, BI.

• Плюсы: сверхбыстрая агрегация, высокая степень сжатия.

• Минусы: медленные точечные обновления (OLTP-нагрузка), сложность реализации.

4. Графовые БД

Хранят сущности (узлы) и связи между ними (рёбра). Оптимизированы для обходов графа.

• Примеры: RedisGraph (модуль Redis), Neo4j (с in-memory режимом).

• Сценарии: социальные сети, рекомендательные системы, сети связей.

• Плюсы: эффективные запросы связей, интуитивная модель для связанных данных.

• Минусы: узкая ниша, сложность шардирования.

5. Time-series БД

Специализированы для временных рядов — метрик, логов, событий. Оптимизированы для записи и запросов по временным интервалам.

• Примеры: InfluxDB, TimescaleDB (in-memory части).

• Сценарии: мониторинг, IoT, финансовые тикеры.

• Плюсы: высокая скорость записи, сжатие старых данных, встроенные функции по времени.

• Минусы: слабо подходят для произвольных данных.

…## 🧭 Наш курс: от Key-Value к документам

Для MemifyDB я выбрал путь, который кажется самым прагматичным:

1. Создаём ядро Key-Value
   Это фундамент. Мы реализуем:

   • потокобезопасное in-memory хранилище;

   • поддержку разных типов значений (строки, списки, хеши, числа);

   • механизмы TTL и эвикшена (LRU);

   • бинарный протокол, близкий к внутреннему представлению.

   Key-value движок даст нам максимальную скорость и стабильность, а также позволит отточить все низкоуровневые механизмы (аллокаторы, сериализацию, сетевое взаимодействие).

2. Надстраиваем документный слой
   Поверх key-value ядра мы добавляем возможность интерпретировать значение как JSON-подобный документ:

   • индексация по полям;

   • поддержка частичного обновления;

   • запросы с фильтрацией по содержимому.

При этом сами документы будут храниться в key-value хранилище как обычные значения, а индексы — как дополнительные структуры (хеш-таблицы, B-деревья) в памяти.

Такая двухслойная архитектура даёт:

• гибкость — можно работать и как с обычным кэшем, и как с документной БД;

• производительность — key-value ядро остаётся быстрым, а документные операции добавляются без потери эффективности;

• расширяемость — позже можно добавить другие модели (например, колоночные агрегаты) как отдельные слои.

Мировой лидер по добыче алмазов АЛРОСА перевел DIrectum RX на СУБД Tantor Postgres, проект занял всего 5 месяцев. При этом бизнес-процессы работали в штатном режиме, сроки не сместились, бюджет не увеличился.

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

23 апреля в 11:00 мск на бесплатном вебинаре эксперты АЛРОСА, «Тантор Лабс», «СТАРКОВ Групп» и Directum поделятся подробностями кейса.

Для участия нужна только регистрация. Встретимся на вебинаре!

🧠 Разбираемся, как устроены in-memory БД: пишем MemifyDB с нуля.

Redis быстр, но не всегда удобен. SAP HANA — мощь, но ценник…
А что, если заглянуть под капот и создать свою enterprise in-memory СУБД?
Не чёрный ящик, а полностью прозрачную, современную, open-source — и при этом готовую к высоким нагрузкам. Разбираемся как это работает!

Знакомьтесь — MemifyDB.

📌 Что это будет?
Настоящая in-memory система уровня enterprise, в которой мы разберёмся до винтика:

• живёт в RAM, отвечает за микросекунды;

• сохраняет данные на диск (RDB + WAL) — никакой потери после ребута;

• реплицируется и шардируется «из коробки»;

• поддерживает транзакции (не хуже MULTI/EXEC, но с возможным rollback);

• и при этом не просит продать почку за лицензию.

Весь код — open source, все решения — с объяснениями.

🛠 Технический фундамент (выбираем стек вместе)
Платформа — JVM. Я сейчас выбираю между Java 21 (Loom) и Scala 3 (ZIO / Akka).

• Сеть: Netty или виртуальные потоки — посмотрим на бенчмарках.

• Память: off-heap + собственный slab-аллокатор на ByteBuffer. GC не мешает, фрагментация под контролем.

• Конкурентность: Lock-Free структуры данных, чтобы не блокировать потоки.

• Протокол: RESP-совместимость — redis-cli сможет общаться с нами.

🗺 Дорожная карта: что и когда разберём

1. Ядро: потокобезопасное KV-хранилище в памяти. Как работают LRU и TTL?

2. Persistence: снапшоты и WAL. Как не потерять данные при краше?

3. Сеть: пишем TCP-сервер. Netty vs Loom — кто быстрее?

4. Транзакции: реализуем MULTI/EXEC, WATCH. Нужен ли MVCC?

5. Репликация и Raft: как достичь консенсуса в распределённой системе?

Каждый этап — открытый код, пост с разбором, грабли и профит.

🤔 Зачем я это делаю публично?
Во‑первых, разобраться самому и дать шанс разобраться другим.
Во‑вторых, фидбек сообщества ловит ошибки на берегу.
В‑третьих, хочется сделать реально полезный инструмент, а не очередной pet‑project.

💬 Вопрос к залу:
Какой стек предпочтительнее для enterprise in‑memory БД — Java 21 + Loom или Scala + ZIO/Akka?
Какие фичи вы бы добавили в дорожную карту?
Пишите в комментариях — лучшие идеи уйдут в реализацию!

👉 Подписывайтесь, чтобы не пропустить:

• глубокий разбор off‑heap аллокатора;

• сравнение моделей конкурентности на реальных бенчмарках;

• историю о том, как одна строка unsafe кода валила прод три дня.