В кінці липня 2016 року в корпоративному блозі Über з'явилася воістину історична стаття про причини переходу компанії з PostgreSQL на MySQL. З тих пір в жарких обговореннях цього матеріалу було зламано чимало списів, аргументи Über були ретельно препаровані; компанію звинуватили в упередженості, технічної неграмотності, нездатності ефективно взаємодіяти з спільнотою та інших смертних гріхах, при цьому по гарячих слідах Postgres було внесено кілька змін, покликаних вирішити деякі з описаних проблем. Список наслідків на цьому не обмежився, і його можна продовжувати ще дуже довго.
Напевно, не буде перебільшенням сказати, що за останні кілька років це було одне з найбільш гучних і резонансних подій, пов'язаних з СУБД PostgreSQL, яку ми, до речі сказати, дуже любимо і широко використовуємо. Ця ситуація напевно пішла на користь не тільки згаданим систем, але і руху Free and Open Source в цілому. При цьому, на жаль, російського перекладу статті так і не з'явилося. Зважаючи на значущість події, а також докладного і цікавого з технічної точки зору викладу матеріалу, в якому стилі Postgres vs MySQL йде порівняння фізичної структури даних на диску, організації первинних і вторинних індексів, реплікації, MVCC, оновлень і підтримки великої кількості сполук, ми вирішили заповнити цей пробіл і зробити переклад оригінальної статті. Результат ви можете знайти під катом.
Читати далі →



Олександр Зайцев відповідає на питання щодо переїзду на Yandex ClickHouse. Це — розшифровка доповіді Highload++ 2016.

Всім здрастуйте! За ці два дні на конференції було два двогодинних митапа, сьогодні навіть майже тригодинний митап за ClickHouse. Після цього Віктор з Олексієм зробили чудовий доповідь, здавалося б, більше вже нічого не розкажеш. Насправді це не так.

Я вам розповім, як на ClickHouse переїжджати, якщо у вас вже є. Зазвичай якщо нічого немає, то все дуже просто. Берете і будуєте на новій системі. А от якщо щось є, то це набагато складніше. Зараз у вас все добре. Ви зрозуміли, що ClickHouse чудова система. Віктор з Олексієм відповідять на всі питання, я не сумніваюся, щоб ще більше запевнити вас в тому, що це правильне рішення.

Насправді, не все так добре, як вони розповідають якщо ви збираєтеся переїжджати. Тому що ClickHouse досить сильно відрізняється від усього що ви мали справу в минулому.

Все це абсолютно новий досить специфічний досвід, він вимагає великої роботи для того, щоб все вийшло добре. Якісь прості речі працюють відразу, наприклад, логи завантажити. А якісь не дуже прості речі працюють зовсім не відразу. Зрештою, я переконаний, що у всіх все вийде, тому що у нас вийшло. Ми прорвалися через всі перешкоди.

Читати далі →

Рідкісний SQL

Вступна
Коли часто стикаєшся з будь-якою технологією, мовою програмування, стандартом, формується певна картина їх можливостей, межі, в яких вони використовуються. Так може тривати досить довго, поки на очі не трапляються приклади, які розширюють затверділі горизонти знання. Сьогодні я хотів би розповісти про таких прикладах і продемонструвати їх для мови SQL. Цікаві і рідкісні конструкції, забуті вираження, незвичні прийоми чекають Вас в цій статті. Кого зацікавив, ласкаво просимо під кат.

Читати далі →

Питання про реляційних субд, на які ніколи не вистачає часу

Вступ
Волею доль, я працюю в enterprise близько 5 років, за цей час набрався пул питань про реляційних базах даних, і вони регулярно спливають у голові перед сном.

Але з'ясовувати докладні відповіді на них дорого з часу, бо відправляють в чудесну країну багатотомних мінлива, лінгвістики & статистики і товстих книг.

Прошу допомоги у спільноти у викоріненні свого і чужого невігластва.
Примітка: відповіді на більшість питань були висвітлені в цієї статті, але розкриті не повністю.

Свої емпіричні припущення заховаю під кат.

Читати далі →

Невелике порівняння продуктивності СУБД «MongoDB vs ClickHouse»

Так як колоночная СУБД ClickHouse (внутрішня розробка Яндекс) стала доступна кожному, вирішив використати цю СУБД замість MongoDB для зберігання аналітичних даних. Перед використанням зробив невеликий тест продуктивності і хочу поділитися результатами з IT співтовариством.

Читати далі →

Firebase: прощання з ілюзіями

Маркетинг став частиною світу розробки. За кількістю зірочок на GitHub визначають, яке з схожих один на одного рішень крутіше, а за кількістю твітів можна спрогнозувати, яка технологія буде розвиватися в найближчі півроку. В таких умовах ми ризикуємо стати жертвами хайпи. Я — став: моє уявлення про Firebase розходилося з реальністю настільки сильно, що розуміння області застосування технології стало для мене справжнім одкровенням. Я хочу поділитися цим розумінням і тим, як все-таки використовувати Firebase правильно.



Читати далі →

І знову про рекурсивних запитів

У цій замітці мова піде про те, як писати рекурсивні запити. Ця Тема піднімалася не раз і не два, але зазвичай все обмежується простими «дерев'яними» випадками: спуститися від вершини до листя, піднятися від вершини до кореня. Ми ж займемося більш складним випадком довільного графа.

Почнемо з того, що повторимо теорію (дуже коротко, тому що з нею все ясно), а потім поговоримо про те, що робити, якщо незрозуміло, як підступитися до реальної задачі, або начебто зрозуміло, але запит вперто не хоче працювати.

Для вправи будемо використовувати демо-базу, докладно описану раніше, і спробуємо написати в ній запит для пошуку найкоротшого шляху з одного аеропорту в інший.


Читати далі →

Як я базу в GIT закачував

День добрий, хабровчане. Більшість продуктів, з якими стикається розробник, зазвичай вимагають розгортання на декількох машинах, які працюють незалежно один від одного. Це породжує одну з типових проблем — розбіжність бази даних на різних серверах, невідповідність ідентифікаторів у таблицях-довідниках і зрозуміло неоднорідність чинності неуважність і пропущених патчів при оновленні БД на конкретній машині. У деяких випадках це виливається в дикі (на мій наївний погляд) концепції типу «ми стовпці ніколи не видаляємо — тільки додаємо».

В інших і зовсім приводить до засмічення бази сміттям з інших майданчиків і до помилок після «найпростішого мержа».

Знайомих з такими ситуаціями, критиків і знають точно, що я винайшов велосипед — запрошую під кат.

Читати далі →

Історія СУБД Oracle — першою комерційно успішною реляційної СУБД

image

До середини 70-х років інформація в базах даних розподілялася за старовинним ієрархічним, або «деревоподібному», принципом, який до цих пір використовується в настільних операційних системах.

Перші прототипи реляційних СУБД існували вже в 70-ті роки ХХ століття. Однак мало хто вірив у можливість добитися ефективної реалізації таких систем. Тим не менше, до кінця 1980-х років реляційні системи зайняли на світовому ринку СУБД домінуюче положення.

У зв'язку з цим багато компаній стали позиціонувати свої СУБД як «реляційні» в рекламних цілях. Але далеко не завжди вони мали для цього достатньо підстав. Тому автор реляційної моделі даних Едгар Кодд в 1985 році опублікував свої знамениті «12 правил Кодда», яким повинна відповідати кожна РСУБД.

Одним з перших прототипів реляційних баз даних була система System R. Це проект компанії IBM, який з'явився в 1976 році. Він надихнув майбутніх засновників Oracle на створення власної реляційної СУБД
Читати далі →

Масштабування ClickHouse, управління міграціями та надсилання запитів з PHP в кластер

У попередньої статті ми поділилися своїм досвідом впровадження та використання СУБД ClickHouse у компанії СМИ2. У поточній статті ми торкнемося питання масштабування, які виникають із збільшенням обсягу аналізованих даних і зростанням навантаження, коли дані вже не можуть зберігатися і оброблятися в рамках одного фізичного сервера. Також ми розповімо про розробленому нами інструменті для міграції DDL-запитів в ClickHouse-кластер.
Два шарда по дві репліки

Читати далі →