Как я поднял базу знаний за 15 минут — без бюджета и опыта
Почему я выбрал именно BookStack
Мы в команде давно искали удобный инструмент для хранения технической документации и инструкций. Пробовали всё подряд — от Wiki.js до Confluence. Но то санкции, то интерфейс перегружен, то кастомизация страдает. В какой-то момент я наткнулся на BookStack — лёгкую, симпатичную open-source платформу на Laravel. Решил попробовать. В итоге — развернул, настроил, и теперь она у нас в проде.
Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.
Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.
На Reddit я наткнулся на статью про обработку создания 100 тысяч коротких URL в секунду1. [Прим. пер.: автор статьи по ссылке создал три варианта системы; третий, наилучший, по его мнению, вариант при помощи кластера-координатора делит нагрузку на несколько ECS-воркеров, использует DynamoDB TransactWrite для пакетных условных вставок, а для устойчивости применяет кэш Redis.]
Какой же это запутанный оверинжиниренный бардак!
Не поймите меня неправильно: я люблю оверинжиниринг, но только в обучающих хобби-проектах. Как сказали многие комментаторы на Reddit, в образовательных учреждениях редко преподают распределённые системы и архитектуру ПО. Когда новички попадают в нашу отрасль, из-за подобных постов, написанных авторитетными на вид техлидами, они могут подумать, что оверинжиниринг — это единственный способ работы. Однако часто решение может быть гораздо проще.
Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.
Всем привет! Меня зовут Диана Бутько, я студентка 3 курса, изучаю информационные системы и программирование. В InfoWatch я пришла на практику, и одной из моих задач стал сравнительный анализ различных методов поиска похожих векторов. Это один из ключевых аспектов машинного обучения и анализа данных, используемых в рекомендательных системах, кластеризации, семантическом поиске и других областях. Но чем больше объем данных, тем важнее становится выбор инструментов: полный перебор векторов требует больших вычислительных ресурсов, а в других алгоритмах порой необходимо балансировать между точностью и скоростью поиска.
В этой статье я сравниваю пять методов поиска похожих векторов:
— полный перебор по евклидову расстоянию с реализацией в Python;
— FAISS с индексами IndexFlatL2 (полный перебор, евклидово расстояние) и IndexIVFFlat (сегментирование по ячейкам, евклидово расстояние);
— векторный поиск в ClickHouse с индексом HNSW и метриками расстояния L2Distance (евклидово расстояние) и cosineDistance (косинусное сходство).
Эволюция цифровых технологий требует постоянного внимания к контролю за состоянием баз данных. Современные корпорации активно используют обширные информационные инфраструктуры, полагаясь на эффективную эксплуатацию и защиту своей информационной архитектуры. Выбор правильного инструмента мониторинга играет важную роль в снижении рисков и повышении устойчивости к внешним угрозам.
Далее представлен перевод статьи “5 things to look for in a database monitoring tool”, который подготовил специалист «Автомакон» специально для русскоязычной аудитории. Исходная публикация посвящена ключевым критериям подбора оптимального инструмента для мониторинга баз данных крупными организациями, столкнувшимися с необходимостью обработки больших объёмов данных и увеличения сложности информационных систем.
Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается фундаментальная сложность. Как заставить кучу разрозненных компонентов работать вместе надежно? Как гарантировать, что данные, размазанные по сети, останутся корректными и доступными? Эта головная боль знакома любому, кто проектировал системы сложнее калькулятора, будь то в требовательном финтехе, динамичном e-commerce или где-либо еще.
И вот тут на помощь (или, скорее, для обозначения поля боя) приходят три понятия: ACID, BASE и теорема CAP. Может показаться, что это сухая теория, но игнорировать их – все равно что выходить в море без компаса и карты. Эти концепции описывают фундаментальные компромиссы, с которыми приходится иметь дело каждому архитектору. Понимание их – не гарантия успеха, но его необходимое условие. Давайте погрузимся в их суть и посмотрим, как они влияют на реальные архитектурные решения.
Меня зовут Олег, и в Яндексе мы с командой занимаемся Python-обвязкой вокруг нашей базы данных YDB. Python знаменит «батарейками в комплекте», широким ассортиментом библиотек на все случаи жизни, включая богатую экосистему для работы с базами данных. Есть свой интерфейс DBAPI (PEP-249), несколько конкурирующих ORM и многочисленные уровни абстракции между софтом и базами. В этой статье — о том, как мы делали полноценную интеграцию нашей базы данных с Apache Superset: чтобы достаточно было выбрать YDB из выпадающего меню и начать визуализировать аналитические данные.
Tarantool Proxy — «умный посредник», который делает работу с кластером Tarantool надежнее, быстрее и проще, беря на себя рутинные задачи вроде балансировки и безопасности. Но изначально Tarantool Proxy был написан на Lua, из-за чего для получения всех профитов от работы с ним нужна была специфическая экспертиза и готовность мириться с некоторыми сопутствующими издержками, что подходило не всем. Поэтому мы решили оптимизировать работу с Tarantool и использовали для этого толстый клиент на Go.
Меня зовут Максим Коновалов, я архитектор Tarantool в VK Tech. В этой статье я расскажу, зачем и как мы уходили от Lua и что получили в итоге.
Каждый, кто работает с PostgreSQL, знает его символ — синего слона. Но задумывались ли вы, откуда он взялся? Его история — это не результат работы дорогого брендингового агентства, а захватывающее повествование о зарождении IT-сообщества, питерских энтузиастах, случайных файлах и том, как «маленький презент» стал мировым символом.
Привет, Хабр! Последние несколько лет я занимаюсь разработкой баз данных ВКонтакте. Аудитория такой крупной соцсети ежедневно генерирует огромные массивы информации.
В этой статье я расскажу про хранилище ВКонтакте: как оно менялось, что мы делаем для оптимизации занятого места и как гарантируем сохранность данных.
Supabase с оценкой в $2 млрд стремительно становится технологическим фундаментом современного вайб-кодинга. Почему разработчики массово переходят на этот бэкенд с открытым исходным кодом, и как PostgreSQL-решение превратилось в незаменимый инструмент для AI-приложений, используемый в 29% стартапов последнего набора Y Combinator? История компании, чья ценность оказалась настолько высокой, что инвестор пролетел 17 часов до отдалённого уголка Новой Зеландии для встречи с её основателем.
В 2017 году мы рассказывали о том, как спроектировали нашу систему поиска сообщений так, чтобы она могла индексировать миллиарды сообщений. Благодаря этому наша поисковая инфраструктура стала высокопроизводительной, экономной, масштабируемой и простой в использовании. Мы решили выбрать Elasticsearch, в котором сообщения Discord шардились по индексам и использовалось логическое пространство имён для сообщений Elasticsearch в двух кластерах Elasticsearch. Сообщения шардились или по серверу Discord (который ниже будем называть гильдией) или по личным сообщениям (DM). Это позволило нам хранить все сообщения гильдии рядом для обеспечения высокой скорости запросов и работать с маленькими, более удобными кластерами. Так как поиском пользуются не все, сообщения индексировались лениво, и мы создали очередь сообщений, позволявшую воркерам получать блоки сообщений для индексирования, чтобы воспользоваться возможностями массового индексирования (bulk-indexing) Elasticsearch.
Но с ростом объёмов Discord наша поисковая инфраструктура начала трещать по швам…
Представьте знакомую ситуацию: утро понедельника, задачи сыпятся одна за другой. Перед вами задача срочно развернуть новый сервис на базе Postgres Pro. Или, возможно, в эти выходные вы обновили железо своего сервера базы данных, увеличили количество CPU и объём RAM. Расскажем, как быстро привести СУБД в состояние, оптимально подходящее новому оборудованию и текущим нагрузкам.
Опыт автоматизации финучета в небольшой IT-команде — честно, с мемами и фейлами. Как ушли от Excel, почему сначала все пошло не по плану, что сэкономили, где накосячили и зачем все-таки это сделали. Без волшебных кнопок, но с выводами, которые помогут другим не наступить на те же грабли.
Представим себе картину из идеального мира данных, в котором всё стабильно, изменений нет и на горизонте не предвидятся. Аналитик полностью согласовал с заказчиком требования к витрине, спроектировал решение и передал в разработку. Разработчики внедрили витрину в продуктивный контур, пользователи счастливы, всё работает корректно — сопровождение разработчиков и аналитиков не требуется. Представили?
Но, как мы знаем, «IT» и «изменения» — синонимы, поэтому в идеальном мире, как гром среди ясного неба, появляются новые требования: разработать инструмент для регулярного добавления в витрину данных новых атрибутов, на текущий момент в неизвестном количестве.
Сразу отмечу, что решения и оценки, о которых пойдёт речь, подбирались для работы с большими данными на стеке технологий Apache Hadoop, где для обработки данных использовали фреймворк Apache Spark, СУБД — Apache Hive для анализа данных, оркестратор — Airflow, данные хранятся в колоночном формате Parquet.
Значения восьми параметров конфигурации мастера (primary, ведущего сервера PostgreSQL) сохраняются в управляющих файлах и изменения их значений передаются через журнал (WAL) на реплики. Если реплика открыта для запросов (hot_standby=on), то значения пяти числовых параметров на реплике должны быть не меньше, чем на мастере, иначе процесс startup прекратит накат (replay) журнальных записей. А после рестарта экземпляры реплик не запустятся. В статье рассматриваются эти параметры особенности изменения их значений.
Значения пяти числовых параметров конфигурации, сохраненных в управляющем файле кластера, можно посмотреть утилитой pg_controldata:
TL;DR
Хотите отслеживать трафик на статическом блоге без Matomo и Google Analytics?
Рассказываю, как с помощью OpenTelemetry, Prometheus, Grafana и небольшого самописного скрипта на JS (Otela) можно элегантно и эффективно следить за посещаемостью — при этом полностью сохранив контроль над своими данными.
