минулій статті ми дізналися, як за допомогою утиліти pg_filedump можна відновити дані, або, принаймні якусь їх частину, повністю вбитої бази даних PostgreSQL. При цьому передбачалося, що ми звідки знаємо номери сегментів, що відповідають таблиці. Якщо ми знаємо частина вмісту таблиці, її сегменти дійсно не складно знайти, наприклад, простим grep'ом. Однак у більш загальному випадку це не так-то просто зробити. До того ж, передбачалося, що ми знаємо точну схему таблиць, що теж далеко не факт. Так от, нещодавно ми з колегами зробили новий патч для pg_filedump, що дозволяє розв'язати названі проблеми.
Читати далі →



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


Раніше (1, 2) ми обґрунтували і продемонстрували можливість існування
просторового індексу, що володіє всіма плюсами звичайного B-Tree — індексу та
не поступається по продуктивності індексу на основі R-Tree.
Під катом узагальнення алгоритму на тривимірний простір, оптимізації та бенчмарки.

Читати далі →

Підвернулася мені задачка розробити універсальний каталог товарів і послуг, за сумісництвом каталог підприємств, документів і чого завгодно ще. В роботі цей «досвід» не згодився, а ідея хороша, по-мою скромну думку :) Хочеться поділитися, і послухати критику.

Каталог передбачає упорядкованість — ієрархію, передбачає безпосередньо зберігання інформації, і звичайно пошук, напевно аналітику… що ще? Більше нічого в голову не приходить.

Тепер по пунктах.

Читати далі →

Для роботи з PostgreSQL на мові С++, є чудова бібліотека libpq.
Бібліотека добре документована, є навіть повний переклад на російську мову, від компанії PostgresPRO.

При написанні серверного бекэнда, зіткнувся з тим, що в цій бібліотеці немає ніякого пулу коннектов, а робота з БД, передбачалася в досить інтенсивному режимі і одного конекту було явно мало. Щоразу встановлювати з'єднання для надсилання отриманих даних, було б просто безглуздям, оскільки з'єднання найдовша операція, вирішено було написати свій пул коннектов.

Читати далі →

PipelineDB — одна з реалізацій нині набирають популярність стриминговых СУБД. Про переваги стриминговых СУБД в різних кейсах ви можете без зусиль прочитати сьогодні на безлічі ресурсів. Дуже просто принцип їх роботи візуалізовано на сайті www.pipelinedb.com у розділі «How It Works».

Конкретно PipelineDB це форк PostgreSQL з додатковою функціональністю, що дозволяє зберігати тільки агреговані дані, розраховуючи дельту з надходить стріму (звідси і назва цього типу СУБД) на льоту. Ці дані зберігаються в спеціальних об'єктах PipelineDB, званих continuous views. Сам же стрім в найпростішому випадку формується із звичайних таблиць, збережених у цій же БД.

Ми розглянемо кейс, в якому на продуктової середовищі у нас вже працює СУБД PostgreSQL версії 9.4+, а нам потрібно отримати її read-only репліку для того, щоб розвантажити основну базу від численних і важких SELECT-запитів, одержуваних від, наприклад, систем звітності, DWH або наших вітрин даних. І після вивчення питання Ви можете вирішити, що саме стриминговая СУБД дуже добре підходить для такого завдання.
Читати далі →

нещодавно Вирішив написати невелике ASP.Net MVC додаток після багаторічної перерви і знаючі люди на Хабре підказали спробувати новий ASP.Net Core, тим більше, що він працює в Лінуксі з коробки без необхідності задіяти mono, і, судячи з останніми тестами, навіть показує непогану продуктивність. За основу взяв аналогічну статтю для Mac, але тут на відміну від надихнула мене статті хочу описати процес покроково в одному місці, для того, щоб не довелося лазити по перехресним посиланням, намагаючись розібратися як встановити незрозуміло для чого призначені програми та пакети. Таке докладний опис процесу можливо допоможе багатьом уникнути граблів, з якими довелося зіткнутися мені. Кілька фраз і малюнків, в частині однаковою для будь-якої платформи, з правками і доповненнями взяті з статті для Mac.


Читати далі →

Привіт, Хабр!

Встала переді мною нещодавно завдання: настроїти максимально надійний кластер серверів PostgreSQL версії 9.6.

За задумом, хотілося отримати кластер, який переживає випадання будь-якого сервера, або навіть декількох серверів, і вміє автоматично вводити в дію сервера після аварій.

Плануючи кластер я простудіював багато статей, як з основної документації до PostgreSQL, так і різних howto, у тому числі з Хабра, і пробував настроїти стандартний кластер з RepMgr, эксперементировал з pgpool.
В цілому воно запрацювало, але у мене періодично спливали проблеми з перемиканнями, потрібно ручне втручання для відновлення після аварій, і т. д.
Загалом я вирішив пошукати ще варіанти.
У результаті де-то (вже не згадаю точно, де) знайшов посилання на прекрасний проект Zalando Patroni, і все заверте…


Читати далі →