PostgreSQL чи MySQL. Як обрати оптимальну базу даних для вашого проєкту

Привіт! Я Костянтин Гобеляк, Node.js Team Lead у MOJAM. У своїй роботі я часто взаємодіяв з різними базами даних, і сьогодні поділюсь аналізом PostgreSQL та MySQL для полегшення вибору між ними. Обидві системи мають свої сильні сторони, проте є ситуації, коли одна з них буде ефективнішою за іншу. Розглянемо основні відмінності PostgreSQL та MySQL, їхні переваги та недоліки.

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

PostgreSQL почав свою історію в 1986 році як проєкт POSTGRES під керівництвом професора Майкла Стоунбрейкера з метою створити передову систему управління базами даних. Ключовим моментом стало впровадження підтримки мови SQL у 1994 році. Також тоді змінили назву на Postgres95, а в 1996 її перейменували на PostgreSQL.

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

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

MySQL з’явилася на ринку в 1995 році. Розроблена шведською компанією MySQL AB, спочатку вона була створена для особистого використання на основі mSQL і низькорівневого інтерфейсу ISAM, який розробники вважали занадто повільним і негнучким. І завдяки сумісності API з системою mSQL вони могли перейти на MySQL.

Приблизно в 1999-2000 роках компанія співпрацювала з Berkeley DB і це дало MySQL підтримку транзакцій. Трохи пізніше з’явилася реплікація, ISAM був вдосконалений і перейменований на MyISAM, інтегрували двигун InnoDB (розробник — Хейккі Туурі). MySQL активно використовується в різних сценаріях — від невеликих вебсайтів до складних корпоративних рішень. Та дає можливість будувати надійну інфраструктуру для хмарних застосунків. Після придбання MySQL компанією Oracle у 2010 році, частина розробників перейшла до проєкту MariaDB, який став відкритою альтернативою.

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

Популярність

На початку 1990-х дуже популярною була легка система керування БД — mSQL. Але після піку популярності в розвитку динамічних вебзастосунків 1994–1997 років, її почала витісняти багатофункціональна MySQL. У 1999 році MySQL випередила mSQL за популярністю і надовго закріпилася серед лідерів ринку.

Своєю чергою, PostgreSQL поступово набирала популярність і лише в останні роки змогла наблизитися до популярності MySQL. Попри те, що з’явилася майже на 10 років раніше. Нижче наведено таблицю популярності двох БД за останні 10 років (рейтинг DB-Engines):

Там добре видно, що популярність MySQL трохи впала, тоді як у PostgreSQL виросла більш ніж утричі.

У 2023 році, згідно з опитуваннями Stack Overflow, PostgreSQL випередив MySQL. А у 2024 роцi вiдрив ще трохи збiльшився. Професійні розробники з більшою ймовірністю будуть використовувати PostgreSQL, тоді як новачки — навпаки MySQL. Детальніше тут: опитування 2023 та опитування 2024.

Також на наступному графіку Google Trends видно зниження популярності MySQL, хоча за цим графіком (посилання працює для залогованих користувачiв в Google) популярність PostgreSQL також трохи просіла.

Такі гіганти, як Instagram, Apple, Spotify, Reddit, Twitch використовують PostgreSQL.

  • Instagram — спочатку використовували MySQL, але перейшли на PostgreSQL для критичних частин системи.
  • Apple — аналогічно, PostgreSQL замінив MySQL як вбудовану БД для macOS, починаючи з OS X Lion.

Разом з тим Facebook, Github, Netflix, YouTube та Uber використовують MySQL як основну БД. Uber свого часу замінив PostgreSQL на MySQL (навіть є стаття про це), а зараз використовує комбінацію MySQL і MyRocks — двигун зберігання, заснований на RocksDB.

Функціонал

Далі ми розглянемо ключовий функціонал обох БД:

Загальні можливості

  • Відповідність ACID присутня в обох БД, але в PostgreSQL вона повна, тоді як MySQL з двигуном MyISAM не підтримує ACID.
  • Обидві БД підтримують мультиверсійність (MySQL з InnoDB), але працюють по-різному: PostgreSQL використовує MVCC, а MySQL має власну реалізацію.
  • RBAC підтримується обома БД, але PostgreSQL підтримує додатковий рівень безпеки — Row Level Security.
  • Реплікація є в обох БД: стандартна фізична реплікація PostgreSQL використовує WAL, тоді як у MySQL — логічна (binlog). Однак PostgreSQL також підтримує логічну реплікацію через режим PUB/SUB, додану нещодавно.
  • Є підтримка резервного копіювання та відновлення.
  • Підтримується партиціонування таблиць (типи Range, List, Hash).
  • Ієрархія об’єктів майже однакова: instance, database, schema (тільки в PostgreSQL), table, column.
  • Плагіни доступні в обох БД, але PostgreSQL більш розширюваний шляхом плагінів (наприклад, PostGIS).

SQL

  • Є підтримка стандарту SQL в обох БД.
  • Обидві БД підтримують набір стандартних SQL-типів, але в PostgreSQL можна створювати власні типи даних.
  • Збережені процедури підтримуються обома БД, але PostgreSQL також дозволяє писати їх на інших мовах, крім SQL.
  • Представлення (views), тригери (triggers), CTE (в MySQL з версії 8.0), а також віконні функції є в обох БД.

DDL

  • Є підтримка всіх основних DDL-операцій: CREATE/ALTER/DROP TABLE/DATABASE/VIEW, а також TRUNCATE TABLE. У MySQL також є можливість RENAME TABLE, у PostgreSQL це робиться через ALTER TABLE table_name RENAME TO new_table_name.
  • Також в обох БД є можливість миттєвого додавання нової колонки: в MySQL з версії 8.0 — ALGORITHM=INSTANT (з версії 8.4 цей алгоритм став стандартним), а в PostgreSQL з версії 11 з’явилася можливість проставляти DEFAULT значення на льоту. До цього воно оновлювало дані в кожному рядку.
ALTER TABLE table_name ADD COLUMN column_name bigint, ALGORITHM=INSTANT;

Statements

  • Підтримуються такі стандартні запити: SELECT/INSERT/UPDATE/DELETE/UNION/WITH, а також підзапити й різноманітні специфічні операції (наприклад, REPLACE у MySQL і MERGE у PostgreSQL).
  • Є повнотекстовий пошук, в обох БД є інвертований індекс (MySQL — FULLTEXT, PostgreSQL — GIN).
  • Є можливість повернення змінених даних: у PostgreSQL це працює на всіх операціях (INSERT, UPDATE, DELETE), тоді як у MySQL це реалізовано частково (недоступно на UPDATE), але в MariaDB це також працює для REPLACE.
INSERT INTO table_name (id, column_name)
VALUES (1, 'value1')
RETURNING *; -- also can return specific columns
  • Обидві СУБД підтримують вставку даних із заміною, але в MySQL є два види такої вставки: REPLACE INTO (якщо спрацьовує обмеження, видаляється запис, викликається ON DELETE CASCADE, а потім вставляється новий) і ON DUPLICATE KEY UPDATE (немає видалень, тому працює швидше). У PostgreSQL є аналогічний механізм ON CONFLICT DO UPDATE, а також є можливість не змінювати нічого у випадку конфлікту — DO NOTHING.

MySQL:

# MySQL
INSERT INTO table_name (id, new_column)
VALUES (1, 'value1')
ON DUPLICATE KEY UPDATE new_column = 'value1';

REPLACE INTO table_name (id, new_column)
SET id = 1, new_column = 'value1';

PostgreSQL:

-- PostgreSQL
INSERT INTO table_name (id, column_name)
VALUES (1, 'value1')
ON CONFLICT DO UPDATE SET column_name = 'value1';

INSERT INTO table_name (id, column_name)
VALUES (1, 'value1')
ON CONFLICT DO NOTHING;
  • PostgreSQL має потужну підтримку регулярних виразів через оператори ~ (пошук відповідності) і ~* (пошук без урахування регістру). MySQL також підтримує регулярні вирази, але через функцію REGEXP і має спрощений синтаксис для роботи з регулярками.
  • EXPLAIN підтримується обома СУБД, але візуальне відображення результатів різниться (це детально розглянемо в іншій статті).

Тепер розглянемо відмінності у функціоналі.

Загальне

  • MySQL — це реляційна база даних, а PostgreSQL — об’єктно-реляційна.
  • У PostgreSQL є тільки один двигун зберігання, тоді як у MySQL їх 15, зокрема, найбільш популярні InnoDB та MyISAM.
  • Модель з’єднань різна: PostgreSQL використовує процес на одне з’єднання, а MySQL — потік (тред). При цьому підході в PostgreSQL краща ізоляція, оскільки доступ до невірної комірки пам’яті викликає збій тільки одного процесу, а не всього сервера БД. Однак цей підхід споживає більше ресурсів, тому рекомендується використовувати пулери з’єднань (наприклад, pgCat або pgBouncer).
  • У баз даних різні ліцензії: MySQL — GNU GPL, PostgreSQL — власна ліцензія в стилі MIT (Open Source).

SQL

  • Views є в обох СУБД, але PostgreSQL пропонує MATERIALIZED VIEWS (це такі ж представлення, але попередньо обчислені, що корисно для оптимізації складних запитів).
CREATE MATERIALIZED VIEW complex_view AS
SELECT *
FROM table_name
WHERE column_name = 'value'
WITH DATA;
  • MySQL підтримує тригери BEFORE і AFTER для INSERT/UPDATE/DELETE, а PostgreSQL підтримує ще й тригер INSTEAD OF для views.

MySQL:

# MySQL
CREATE TRIGGER total_amount BEFORE INSERT ON table_name
FOR EACH ROW SET @sum = @sum + NEW.amount;

CREATE TRIGGER total_amount AFTER DELETE ON table_name
FOR EACH ROW SET @sum = @sum - OLD.amount;

PostgreSQL:

-- PostgreSQL
CREATE TRIGGER trigger_name
INSTEAD OF INSERT OR UPDATE OR DELETE
ON table_name
FOR EACH ROW
EXECUTE FUNCTION fn_trigger;
  • Основна відмінність збережених процедур у тому, що в PostgreSQL до версії 11 використовувалися функції для виконання процедурних операцій, а починаючи з версії 11 додані повноцінні процедури. У MySQL завжди існувало чітке розділення між функціями та процедурами.

DDL

  • MySQL підтримує команди SHOW statements, за допомогою яких можна переглянути системну інформацію (список БД, таблиць, колонок тощо), тоді як у PostgreSQL є псевдоніми для клієнта \l, \dt, \d+ table_name. Але якщо потрібно зробити це за допомогою SQL, то запити будуть трохи складнішими.
-- SHOW DATABASES;
SELECT datname FROM pg_database;

-- SHOW TABLES;
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';

-- SHOW COLUMNS FROM table_name;
SELECT column_name FROM information_schema.columns WHERE table_name = 'table_name';
  • В операціях DROP TABLE і TRUNCATE TABLE у PostgreSQL є опція CASCADE, на відміну від MySQL.
TRUNCATE TABLE table_name CASCADE;
DROP TABLE table_name CASCADE;
  • Є нюанс у роботі TRUNCATE TABLE у PostgreSQL: якщо виконати цю операцію в межах іншої транзакції, то при відкаті транзакції операція також відкотиться. У MySQL такої можливості немає.
  • MySQL дозволяє при додаванні нової колонки вказати, після якої колонки її потрібно створити, у PostgreSQL такої можливості немає — нові колонки завжди додаються в кінець таблиці.
ALTER TABLE table_name ADD COLUMN new_column varchar(255) AFTER id;
  • Є різниця в автоматичній генерації ID: у MySQL це AUTO_INCREMENT, який зберігається як атрибут таблиці, а в PostgreSQL це псевдотип SERIAL, що є спеціальним об’єктом БД, який фактично є набором команд DDL під капотом.
CREATE TABLE table_name(
id SERIAL
);

-- ||
-- ||
-- ||
-- \/

CREATE SEQUENCE table_name_id_seq;

CREATE TABLE table_name (
id integer NOT NULL DEFAULT nextval('table_name_id_seq')
);

ALTER SEQUENCE table_name_id_seq OWNED BY table_name.id;

Statements

  • У MySQL є невидимі колонки, це колонки, які невидимі під час запиту SELECT *, але їх можна отримати, якщо безпосередньо вказати їх у вибірці.
CREATE TABLE table_name (
id INT PRIMARY KEY,
new_column VARCHAR(255) INVISIBLE
);

ALTER TABLE table_name CHANGE COLUMN new_column new_column VARCHAR(255) INVISIBLE;
ALTER TABLE table_name MODIFY COLUMN new_column VARCHAR(255) INVISIBLE;
ALTER TABLE table_name ALTER COLUMN new_column SET VISIBLE;
  • У PostgreSQL можна виконувати операції SELECT/UPDATE/INSERT/DELETE всередині CTE (Common Table Expressions) та в запитах після CTE. У MySQL всередині CTE можна лише SELECT, а в запитах після CTE — SELECT/UPDATE/DELETE.
  • PostgreSQL підтримує стандартний SQL-підхід до обробки NULL. Для порівняння значень NULL використовується IS NULL або IS NOT NULL. У MySQL нестандартна поведінка під час використання оператора = із NULL. Наприклад, NULL = NULL повертає NULL, а не TRUE, що може призвести до неочікуваних результатів при некоректній обробці значень NULL. Тому при роботі з NULL завжди потрібно використовувати IS NULL або IS NOT NULL для коректного порівняння.
  • У MySQL можна використовувати спрощений синтаксис для LIMIT із вказівкою зміщення та кількості рядків, чого немає в PostgreSQL.

MySQL:

# MySQL
SELECT * FROM table_name LIMIT 10, 5;

PostgreSQL:

-- PostgreSQL
SELECT * FROM table_name LIMIT 10 OFFSET 5;
  • PostgreSQL використовує оператор || для об’єднання рядків, тоді як у MySQL для цього використовується функція CONCAT().
  • PostgreSQL повністю підтримує оператор FULL OUTER JOIN, який повертає рядки, що є в одній або обох таблицях. MySQL не підтримує FULL OUTER JOIN напряму. Для цього необхідно використовувати комбінацію LEFT JOIN і RIGHT JOIN з об’єднанням результатів за допомогою UNION.

MySQL:

# MySQL
SELECT * FROM table_name t LEFT JOIN second_table_name s ON t.id = s.table_name_id
UNION
SELECT * FROM table_name t RIGHT JOIN second_table_name s ON t.id = s.table_name_id;

PostgreSQL:

-- PostgreSQL
SELECT * FROM table_name t FULL OUTER JOIN second_table_name s ON t.id = s.table_name_id;

Далі розглянемо основні типи даних.

У обох СУБД є такі типи даних:

  • числові;
  • дата і час;
  • рядкові;
  • просторові;
  • JSON.

Числові:

  • У MySQL є signed/unsigned integers різної довжини (1, 2, 3, 4 і 8 байтів), тоді як у PostgreSQL є лише signed integers довжиною 2, 4 і 8 байтів.
  • Для зберігання точних числових значень можна використовувати тип NUMERIC. Цей тип реалізовано як DECIMAL. Однак операції з цим типом даних важчі для СУБД, ніж з integer.
  • Числа з плавучою точкою представлені типами FLOAT і DOUBLE у MySQL, REAL і DOUBLE PRECISION у PostgreSQL.
  • Є тип BIT, який потрібен для зберігання бітових значень.
  • PostgreSQL має тип money із фіксованою дробовою точністю (налаштовується через опцію lc_monetary).
  • Також у PostgreSQL є спеціальний тип для зберігання автоінкрементних колонок — SMALLSERIAL, SERIAL і BIGSERIAL.
  • Обидві СУБД підтримують тип boolean, але у PostgreSQL він нативний, а у MySQL це псевдонім для tinyint(1) під капотом. У MySQL можна використовувати вирази TRUE і FALSE, які автоматично приведуться до 1 і 0 відповідно.

Дата і час:

  • Обидві СУБД підтримують тип TIMESTAMP, але їхні діапазони різні: у MySQL це від 1970-01-01 00:00:01.000000 UTC до 2038-01-19 03:14:07.499999, а в PostgreSQL — від 4713 р. до н.е. до 294276 р. н.е. Також у MySQL цей тип вказує часовий пояс UTC, а в PostgreSQL є додатковий тип timestamptz, який повертає дату й час у вказаній зоні (timezone), але під капотом усе одно зберігає значення в UTC.
  • Типи DATE і TIME присутні в обох СУБД (у PostgreSQL також є timetz).
  • У MySQL є тип DATETIME з діапазоном від 1000-01-01 00:00:00.000000 до 9999-12-31 23:59:59.499999 і повертається у вигляді YYYY-MM-DD hh:mm.
  • Також у MySQL є тип YEAR з діапазоном від 1901 до 2155 і 0000.
  • У PostgreSQL є власний тип INTERVAL, який дозволяє зберігати й обробляти періоди в роках, місяцях, днях, годинах, хвилинах і секундах. Цей тип корисний для арифметики над датами й часом. У MySQL також є INTERVAL, але він є оператором.

Нижче наведено вибірку даних за останні 30 днів, за винятком останніх 2 — запит однаковий для обох СУБД.

SELECT *
FROM table_name
WHERE created_at BETWEEN NOW() - INTERVAL '30 days' AND NOW() - INTERVAL '2 days';

Рядкові:

  • Обидві СУБД мають рядки фіксованої довжини (CHAR) і змінної довжини з лімітом (VARCHAR).
  • Для зберігання великого тексту використовується тип TEXT, але у MySQL він розділений на чотири типи: TINYTEXT, TEXT, MEDIUMTEXT і LONGTEXT.
  • Для зберігання бінарних даних у MySQL використовується тип BLOB, представлений чотирма типами: TINYBLOB, BLOB, MEDIUMBLOB і LONGBLOB (також є для дрібних даних BINARY і VARBINARY, подібні до CHAR і VARCHAR, тільки в бінарному виконанні), а в PostgreSQL — BYTEA. Виведення бінарних рядків відбувається за допомогою шістнадцяткової нотації в MySQL, а в PostgreSQL за замовчуванням за допомогою послідовності символів ASCII, але є можливість також використовувати шістнадцяткову систему.
  • Також в обох СУБД є тип перерахування ENUM, але використовується він трохи по-різному: у MySQL його можна вказувати одразу під час додавання колонки, а в PostgreSQL потрібно окремо створювати власний тип (про це поговоримо трохи пізніше).

MySQL:

# MySQL
ALTER TABLE table_name ADD COLUMN status ENUM('active', 'inactive') DEFAULT 'active';

PostgreSQL:

-- PostgreSQL
CREATE TYPE status_type AS ENUM ('active', 'inactive');
ALTER TABLE table_name ADD COLUMN status status_type DEFAULT 'active';
  • У PostgreSQL неможливо видалити значення з уже створеного типу enum і змінити сортування. А в MySQL це можливо, але для видалення потрібно змінити всі видаляємі значення в колонках таблиці на інше доступне.
  • У MySQL також є тип SET, який схожий на ENUM, але має трохи розширену функціональність. Якщо взяти за аналогію HTML-перемикачі, то ENUM — це radio button, а SET — checkbox.

Просторові:

Коли йдеться про просторові запити, обидві СУБД мають свої слабкі та сильні сторони.

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

JSON:

PostgreSQL підтримує два типи:

  • JSON — зберігає дані як рядок, перевіряє лише коректність синтаксису JSON під час запису, але не перевіряє структуру або типи даних.
  • JSONB — це двійковий формат зберігання JSON, де дані парсяться й індексуються, що робить його більш продуктивним для операцій пошуку. Для інтенсивних операцій читання й модифікації JSON краще використовувати тип JSONB, оскільки він швидший для пошуку й дозволяє створювати індекси. Тип JSON більше підходить для випадків, коли потрібно просто зберігати дані у форматі JSON без частих операцій пошуку.

MySQL підтримує тільки один тип JSON, який також перевіряє коректність синтаксису під час запису даних, але зберігає їх у двійковому вигляді, аналогічно до PostgreSQL JSONB. У PostgreSQL використовуються оператори та функції для роботи з JSON, тоді як у MySQL — тільки функції.

  • PostgreSQL має повну підтримку операцій із JSON: можливість витягнення даних, перетворення, фільтрації та навіть модифікації JSON-структур.
  • У MySQL підтримується доступ до значень за ключами та створення вкладених запитів для фільтрації даних усередині JSON.

Однією з головних переваг PostgreSQL є ефективна індексація полів JSONB, що дозволяє створювати індекси за конкретними ключами або значеннями всередині JSON-структур за допомогою індексів GIN або B-tree.

У MySQL індексація всередині полів JSON безпосередньо не підтримується. Однак можна створювати віртуальні колонки на основі даних JSON та індексувати їх. Наприклад, можна витягти значення з JSON і створити індекс на віртуальній колонці.

CREATE TABLE table_name (
id INT AUTO_INCREMENT PRIMARY KEY,
new_column JSON,
col_data VARCHAR(100) AS (JSON_UNQUOTE(JSON_EXTRACT(new_column, '$.col_data'))) VIRTUAL
);

MySQL надає хороший набір функцій для роботи з JSON, але його підтримка індексів для полів усередині JSON не така гнучка, як у PostgreSQL. В операціях пошуку та фільтрації даних JSON PostgreSQL з JSONB може бути більш продуктивним завдяки просунутій підтримці індексів.

Нижче порівняння основних операцій:

Додаткові типи:

  • У PostgreSQL також є тип UUID (Universally Unique Identifier), який зберігає унікальні ідентифікатори за стандартом RFC 4122. Це робить роботу з UUID більш зручною та ефективною, оскільки PostgreSQL підтримує цей тип даних на рівні ядра. У MySQL є вбудована функція UUID(), яка генерує унікальні ідентифікатори у форматі UUID. Однак MySQL не надає спеціального типу даних для зберігання UUID і зазвичай розробники використовують типи CHAR(36) або BINARY(16) для їх зберігання.
  • Крім того, PostgreSQL має вбудовані типи даних для роботи з мережевими адресами (Network Address Types), які призначені для зберігання та обробки IP-адрес, масок підмереж та інших мережевих даних. Ці типи даних дозволяють виконувати ефективні операції порівняння, фільтрації та інших маніпуляцій з IP-адресами та масками мереж. Основні типи даних такі: INET — для зберігання IPv4 та IPv6 адрес, CIDR — для зберігання блоків мереж IPv4 і IPv6, MACADDR — для зберігання MAC-адрес, MACADDR — для зберігання 8-байтових MAC-адрес (використовується для розширених форматів MAC-адрес).

Користувацькі типи даних:

І нарешті, PostgreSQL має потужний функціонал для створення користувацьких типів даних, що дозволяє розробникам визначати власні структури даних, розширюючи можливості бази даних під конкретні завдання. Цей функціонал підтримує кілька видів користувацьких типів, включаючи складені типи, перерахування (ENUM), масиви, псевдоніми типів, доменні типи, а також складніші, такі як типізація на основі C-функцій (для інтеграції зовнішніх типів).

  • Складений тип (Composite Types) даних — це тип, який являє собою набір полів (атрибутів), кожен із яких може мати свій тип. Це схоже на створення структур або об’єктів в інших мовах програмування.
CREATE TYPE full_name AS (
first_name VARCHAR(50),
last_name VARCHAR(50)
);

ALTER TABLE table_name ADD COLUMN name full_name;

INSERT INTO table_name (name) VALUES (ROW('John', 'Doe'));

SELECT (name).first_name, (name).last_name FROM table_name;
  • Типи ENUM дозволяють створювати набір передвизначених значень, які являють собою рядкові дані. Це корисно для створення обмежених списків варіантів.
  • Доменний тип (Domains) — це спосіб створення нового типу на основі наявного з додатковими обмеженнями та правилами. Це корисно для застосування бізнес-правил.
CREATE DOMAIN positive_integer AS INTEGER
CHECK (VALUE > 0);
  • PostgreSQL дозволяє створювати масиви з будь-яких наявних типів даних, включаючи користувацькі типи, такі як ENUM або складені типи.
ALTER TABLE table_name ADD COLUMN grades INTEGER[];
INSERT INTO table_name (grades) VALUES ('{4,3,5}');
SELECT grades[1] FROM table_name;
  • Псевдоніми типів (Type Aliases) дозволяють створювати зручніші назви для наявних типів даних. Це корисно, якщо потрібно використовувати довгі або незручні типи даних і ви хочете спростити код.
CREATE TYPE price AS NUMERIC(12, 2);
  • PostgreSQL дозволяє створювати базові типи даних за допомогою зовнішніх бібліотек на мовах програмування — таких, як C. Це складніший варіант, який вимагає створення нових типів даних на рівні ядра PostgreSQL. Користувацькі базові типи можуть містити складні структури даних і поведінку, які не можна реалізувати за допомогою стандартних можливостей SQL.

Основні етапи створення користувацького базового типу:

  1. Написання функції мовою C для реалізації нового типу.
  2. Реєстрація нового типу в PostgreSQL за допомогою команди CREATE TYPE.
  3. Налаштування операторів і функцій для роботи з типом (наприклад, як дані будуть серіалізуватися, десеріалізуватися, індексуватися тощо).

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

Висновки

PostgreSQL і MySQL — це дві популярні реляційні бази даних, кожна з яких має свої сильні сторони та відповідає різним завданням. У цій статті ми поринули в історію, розглянули основні відмінності між ними та властивості, що притаманні цим БД

Якщо підсумувати:

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

Вибір між цими двома СУБД має ґрунтуватися на вимогах проєкту та складності запитів.

У наступній частині статті розглянемо процеси та роботу PostgreSQL і MySQL зсередини. Це дозволить детальніше зануритися в конкретні ситуації й краще зрозуміти, яку з баз даних доцільно використовувати в кожній з них.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось31
До обраногоВ обраному25
LinkedIn

Найкращі коментарі пропустити

Щоб обрати базу даних, немає сенсу розглядати такі мінорні деталі як перейменування таблиць, або список стандартних запитів. Важливо інше:
— Які є розширення моделі даних за межами звичайних типів (в тому ж PostgreSQL підтримуються масиви, JSONB, композитні типи, спеціалізоване розширення для тайм серій TimescaleDB та багато чого іншого).
— Які типи індексів підтримуються.
— Як працює блокування — чим більше блокувань, тим гірше БД справляється з частим оновленням.
— В яких сценаріях забезпечується транзакційність, в яких — ні.
— Які є підводні камені реалізації транзакційності (в тому ж PostgreSQL це про vacuum та wraparound).
— Які є публічні бенчмарки, що показують як кожна база себе поводить в різних патернах навантаження на різних об’ємах даних.
— Як забезпечується висока доступність.
— Які способи масштабування підтримуються (наприклад, за допомогою розширення Citus для PostgreSQL можна будувати кластер із шардів).
— Чи є рішення для реалізації zero-downtime schema evolution і чи є якісь підводні камені з цим.
— Які є відомі системи побудовані на тій чи іншій базі. Але тут треба більше деталей, щоби бути об’єктивним. Бо є рішення на тому ж MySQL де від нього, грубо кажучи, тільки назва, а під капотом насправді щось дуже кастомне заточене під конкретну задачу.
...

Якщо є потреба поганяти бенчмарки на різних базах — є моя тула в опенсорсі github.com/...​riyIvon/DatabaseBenchmark (на правах реклами :))

Тут я бачу багато фанатів Оракла і багато коментів, навіть не знаю на який відповідати... Тому прокоментую всі.

А потім оце усе забрати в купку, викинути на смітник і поставити нормальний Оракл
є оракл для великих обсягів даних, постгрес на таких навантаженнях ляже тай усе

Чомусь я міграції з Оракла на щось інше бачив, а в зворотному напрямку — ні. Приклади великих систем які використовують Open Source рішення:
— MySQL — Uber, Booking, GitHub, Wikipedia, etc.
— PostgreSQL — Instagram, iTunes, iCloud, Spotify, Reddit, Skype, etc.

Як думаєте, їм доведеться переходити на Оракл, коли об’єм даних стане великим, чи не факт?

бо в оракла краща архітектура
оракл більш стійкий бо там продумана архітектура

Можна детальніше, в чому вона краща? Реально цікаво.

це не головне, я про відмовостійкість до якої іншим скбд як до луни

Щодо надійності в цілому... Я тісно працював з Ораклом між 2006 і 2013 роками. З інтервалом десь в рік чи два зустрів два офіційних патча які в хлам розламували вичитку даних. Це приблизно на два більше ніж у інших СУБД з якими я працював.

Тут вже згадували посилання про культуру розробки ядра Ораклу — news.ycombinator.com/item?id=18442637

А щодо відмовостійкості — крім Оракла більш ніхто не вміє в Highly Available кластери?

звісно це провокативне питання, але я вважаю що «інстумент повинен бути якісним», а наскільки ці ваші бд відсталі порівняно з ораклом — жах

Відсталі в чому? Можна більше деталей без загального «в нього краще архітектура»?

щодо «економії»... у кожного свій досвід але задумайтесь — навіщо економити гроші дяді у якого й так три лексуса :)

Компанії зацікавлені в зменшенні витрат. Як пояснити замовнику на пальцях що мінімум 17500 доларів за процесор на рік + відсоток за сапорт — це необхідність для системи. Пояснення «в нього архітектура краще» не підійде.

І щоб не було непорозуміння — в Оракла є свої сильні сторони, спору нема, але вони вже давно як не безальтернативні. Той же MS SQL в ентерпрайз середовищі — сильний конкурент з багатим набором фіч, і при цьому дешевший. А вартість самого Ораклу і складність його сапорту (що знову ж таки значить «вартість») примушує багато компаній замислитися а за що вони насправді платять і чи не має сенсу позбутися цієї статті витрат.

Мені так забавно чути доводи про обʼєм БД, що потягне Оракл, та не потягнуть інші — у мене є відразу 2 зауваження. Я особисто бачив для всіх трьох (і ще MSSQL, але там було трохи менше Тб) БД більше кількох Тб, і питання перше — чи багато ви знаєте проектів де реально аж такі обʼєми?

Питання друге, основна перевага БД у використанні транзакцій. І тут цікаво те, що саме транзакційних даних, тобто таблиць на яких виконуються транзакції та де вони реально важливі, серед отих кількох ТБ — скільки?

Бо пихати блоби у БД як у файлову систему, це не ознака розуму, вибачте. Купу разів бачив. Якщо у вас блоби, які не потребують транзакцій — візьміть файлову систему чи документ-орієнтовану базу, що легко шардиться — Mongo/Cassandra/etc і не знущайтеся над собою і залізом.

Я не кажу, що не буває, коли вам всі терабайти треба мати в транзакціях, але вірогідність таке зустріти, ну, скажемо так, не дуже висока. Таких корпорацій (і їх БД) можна перерахувати по пальцях. У більшості випадків ви такі обʼєми або не побачите, або їх можна, навіть треба зберігати не в транзакційній БД.

Колись бачив проект, де сканували паперові документи у PDF і пхали в БД — потім розказували, що серверів не вистачає, не дуже швидко, казали, працює :):):) Треба докупляти... дуже сумно, що залізо докупити можна, а мізки — ні. ;)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

> У MySQL нестандартна поведінка під час використання оператора = із NULL. Наприклад, NULL = NULL повертає NULL, а не TRUE, що може призвести до неочікуваних результатів при некоректній обробці значень NULL.

Як раз за стандартом NULL=NULL має давати NULL. Текст стандарту можна знайти і переконатись самому.
Проблема «чи має none дорівнювати undefined» загально відома і використання NULL для обох це типова диверсія з боку майже кожного проектувальника БД.

> Тому при роботі з NULL завжди потрібно використовувати IS NULL або IS NOT NULL для коректного порівняння.

Є таке. І це проблема для будь-якої БД.

> MACADDR — для зберігання MAC-адрес, MACADDR — для зберігання 8-байтових MAC-адрес (використовується для розширених форматів MAC-адрес).

Я розумію, тут щось переплутане.

8 байтів це мало. В Infiniband треба 20 байтів.

Як раз за стандартом NULL=NULL має давати NULL

И вы можете привести ссылку на стандарт/параграф стандарта?

Да пожалуйста. Вот например ISO 9075-2 (“Foundation”) в версии 2011:

4.5.2 Comparison and assignment of booleans
All boolean values and SQL truth values are comparable and all are assignable to a site of type boolean. The value True is greater than the value False, and any comparison involving the null value or an Unknown truth value will return an Unknown result. The values True and False may be assigned to any site having a boolean data type; assignment of Unknown, or the null value, is subject to the nullability characteristic of the target.

“and any comparison involving the null value or an Unknown truth value will return an Unknown result” — ключевое.

А вот в 1992 пункт “8.2 <comparison predicate>”, покрывающий все проверки типа X=Y, X>Y и так далее:

a) If XV or YV is the null value, then “X <comp op> Y” is unknown.

(XV, YV — X value, Y value. Язык стандарта очень тяжёлый.)

Если вы хотите придраться к тому, что null и Unknown разные, то я согласен, но MySQL и большинство остальных движков их приравнивает без потери смысла. А вот что не будет в этом случае TRUE — сказано явно и именно это тут существенно.

Вопросы?

Вопросы?

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

кстати, так чему будет равен null = null, тру или фальш?

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

Проблема именно в том, что на стандарт плюют 99% DBA, и авторам движков приходится под это подделываться.
Стандартный NULL предназначен, лучше считать, только для внутренних трюков только «чем заполнять при right join». А для ситуаций типа «у этого человека в принципе нет отчества» предназначены другие значения, и для этого надо расширять домен значений.

Но так как всем плевать — то и получается фигня. Вот MySQL для фигнестроителей и выставил упрощённый режим.

Или ты по стандарту делаешь глупости — или ты делаешь «по уму» — но тогда будь бобёр — не говори что ты — «соотвествуешь стандарту»

И я подозреваю, что вы тоже сплошь и рядом используете NULL как затычку для отсутствия значения. Не?

кстати, так чему будет равен null = null, тру или фальш?

А вы перестали пить коньяк по утрам?

Проблема именно в том, что на стандарт плюют 99% DBA

Я подушню немного, но налл и их сравнение — єто скорее к девелоперам,а не к ДБА
Хотя дба, разумеется, об єтом тоже прекрасно знают

Стандартный NULL предназначен, лучше считать, только для внутренних трюков только «чем заполнять при right join»

прекрасно.....

А для ситуаций типа «у этого человека в принципе нет отчества» предназначены другие значения,

К примеру?

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

почему — затычка? Стандартное решение
А вы, я так понимаю, испольуете другие подходы? какие? «магические значениея» или парный к полю флаг «Значения нет»?

А вы перестали пить коньяк по утрам?

Даже не начинал. Я трезвенник, причем крайне агрессивный.

Я подушню немного, но налл и их сравнение — єто скорее к девелоперам,а не к ДБА

Решение, что как хранить на каком уровне, это скорее таки к архитектору базы, не? Девелоперы будут уже действовать в соответствии с принятым решением. Какие таблицы вообще есть, какие НФ нарушать для скорости, что режется на отдельные атрибуты, а что нет, что зажато в домены и справочники, а что нет, выбранная коллация, и ещё 100500 тонкостей.

К примеру?

Для данного примера — лучше всего пустая строка. Конечно, тут повезло, что в домене бизнес-значений такого нет, и мы можем применить такое значение под спецроль.

почему — затычка? Стандартное решение

Да вот из-за проблем типа «а если нам нужно отсутствие отчества, мы должны сформировать select с `is null` вместо универсального `=`». Теперь представим себе, что таких полей несколько, и, например, всю эффективность предкомпилированных шаблонных операторов мы уже теряем.

А вы, я так понимаю, испольуете другие подходы? какие? «магические значениея» или парный к полю флаг «Значения нет»?

В основном таки «магические».

Даже не начинал.

Ну вот и я не давал ни true ни false :))

Решение, что как хранить на каком уровне, это скорее таки к архитектору базы, не?

Ну и причем тут ДБА — администратор, которій занимается сопровождением и єксплуатацией?

какие НФ нарушать для скорости,

Никакие

Для данного примера — лучше всего пустая строка

Пнятненько.....

В основном таки «магические».

Пнятненько....

Ну и причем тут ДБА — администратор, которій занимается сопровождением и єксплуатацией?

На вашей планете DBA — database administrator и только?
Везде где я таких видел — это ещё и database architect, причём обычно происходит совмещение — как минимум за ним главное слово в вопросах «на какие грабли мы наступили/наступим и как вообще правильно (надо было) делать». Книги для DBA тоже содержат обычно обе тематики.

Пнятненько.....

Количество точек что-то обозначает?

Везде где я таких видел — это ещё и database architect,

Он у вас там случайно принтері еще не заправляет, нет? а чо, онжепрограмист :)

причём обычно происходит совмещение

А, он у ввас еще и полі моет, по совместительству....

Количество точек что-то обозначает?

Почитайте книги по грамматике или чо там, должно біть написано чо такое многоточие и когда применяется

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

Он у вас там случайно принтері еще не заправляет, нет? а чо, онжепрограмист :)

Не-а. Принтеры заправляют phpʼшники, когда они есть.

Почитайте книги по грамматике или чо там, должно біть написано чо такое многоточие и когда применяется

Там нет описания символов «4 точки» и «5 точек».
Это, наверно, у вас 🐞 такие ползали в момент написания?

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

Это хорошо. А то, знаете ли, есть ещё и database analyst...

Не-а. Принтеры заправляют phpʼшники, когда они есть.

Не могу не одобрить

Там нет описания символов «4 точки» и «5 точек».

А ві все книги проверили?

Это хорошо. А то, знаете ли, есть ещё и database analyst...

У меня в отделе, кстати, есть :)
но правда тут надо понимать в какую сторону — в сторону данніх, или в сторону структур (хотя в сторону структур без данніх — оно будет тяжело)
У меня — в сторону структур и кода, потому как тяжело уже без него.

На вашей планете DBA — database administrator и только?

Интересно, как скоро участники дискурса придут к мысли, что в зависимости от размера компании / сложности системы там может быть либо некий «DBA», который одновременно и сисадмин, и администратор БД, и БД разработчик и вообще человек-оркестр — либо отдельно архитекторы, администраторы, разработчики, дата-инженегры и прочие аналитики.

вообще человек-оркестр

Я єто назіваю «рабочий пяти и более специальностей», и пропагандирую місль что хороший дба всё это делать уметь быть должен, но не обязан.

Хз. Встречал точку зрения, что хороший ДБА зачастую плохой дев и наоборот.
Это не значит, впрочем, что дба не в состоянии написать немножко кода бизнес-логики, а дев не может развернуть бэкап.

Хз. Встречал точку зрения, что хороший ДБА зачастую плохой дев и наоборот.

Вообще говоря — да. И та и другая область довольно широка и сложно быть отличным работником и там и там.
Однако понимать концепции, уметь пусть не «писать», но «читать» — это очень помогает в работе.
тут вот есть какой-то перс, всё бегает за мной с тем что я рассказывал про «мьютексы», мол «а зачем они?!?!»
Ну так для общей широты картины. Иногда это и правда нахер не надо. А иногда и надо. В БД то, не понимать основы многозадачности, синхронизации и т.д. — ну нонсен же!

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

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

В даному випадку MySQL притримується стандартів і у нього null = null -> null
MySQL під рукою нема, але є Марія — там так само:

MariaDB [(none)]> select null = null\G
*************************** 1. row ***************************
null = null: NULL

А також null <> null -> null

MariaDB [(none)]> select null <> null\G
*************************** 1. row ***************************
null <> null: NULL

Просто з null-ами у нас виходить 3-тична логіка — true, false, null — і якщо її застосувати у if-ах чи case-ах, то вона має якось відмапитись на 2-кову логіку, де тільки true і false, відповідно null зводиться до не-true, а отже false:

MariaDB [(none)]> select case when null = null then 1 else 0 end\G
*************************** 1. row ***************************
case when null = null then 1 else 0 end: 0

До речі, ця поведінка дозволяє провернути на MySQL трюк із unique constraint для null-абельних полів, де можна тримати тільки унікальні значення і багато «не-унікальних» з null.
Наприклад, для MSSQL таке робиться із труднощами — через умовні constraints які з’явились вроді тільки у 2018 версії.

Наприклад, для MSSQL таке робиться із труднощами — через умовні constraints які з’явились вроді тільки у 2018 версії.

Имеется в виду — filtered indexes?

Имеется в виду — filtered indexes?

Ага, вони саме

1. Тут я мабуть не так висловився, малося на увазi, що це неочiкувана поведiнка для тих хто не в темi, а взагалi то так це за стандартом SQL.
2. Згоден.
3. Там загубилася цифра у другому згадуванні значення MACADDR має бути MACADDR8. I вони займають по 6 та 8 байтiв.
www.postgresql.org/...​t/datatype-net-types.html

Як обирається БД.
В теорії. Аналізуємо доступні типи даних, що там по транзакціях, типи індексів, реплікації/шардинги, вартість обслуговування...
В житті. Хтось працював з Postgre? Ну то вирішили тоді.

Коли плануєте наступну частину циклу?

Десь ближче до лiта, бо зараз багато роботи навалилося, а розiбрати пiдкапотну частину потребує багато часу

Спробуйте MariaDB замість MySQL.
Подивіться ще в бік Cassandra.
Для різних задач різні бази даних.
MySQL and MariaDB are both open source relational databases with comparable structure and functionality. But because Oracle owns MySQL, many users find themselves on a fast track to vendor-lock in with other proprietary solutions, such as Oracle Cloud and Oracle Heatwave. By contrast, MariaDB prioritizes flexibility and freedom for users. Our open source relational database started as a fork of MySQL and maintains protocol compatibility with MySQL. Our database experts — including the original core MySQL team — bring the best of database technology without vendor lock-in.

Як я вже писав нижче, mysql все ж таки поки що бiльш популярний, але я планую трохи розглянути форки percona db та mariadb в другiй статтi. А Cassandra це трохи для iнших цiлей.

Доречі оракл взагалі не вивозить в порівнянні з Microsoft SQL Server. Думаю по кількості вбудованих оптимізацій та зручності вона топ 1. Оракл вже давно не топ, застарілий артефакт древності за оверпрайс. Кусок легасі. Тобто оракл це минуле, він зараз тримається тільки на старих ентерпрайз клієнтах, питання його смерті лише справа часу.

Доречі оракл взагалі не вивозить в порівнянні з Microsoft SQL Server.

когда-то было время, когда я учайствовал в переводе проектов с оракула на скуль
мои тогдашние наблюдения:
1. В исходном виде, когда код написан через жопу криворуким индусом — оракул всё равно выгребет и будет боль мень вменяемо работать.Скуль в такой ситуации сдохнет
2. В том случае, если приложить опыт в оптимизации — скуль даёт результаты лучше чем оракул
3. Во многих местах оракула, благодаря богатсву его фич, код написан абсолютно через жопу. «неоптимально» — это вообще не то слово.

Про оракл неоднократно писали, что он поддерживает совместимость чуть ли не с 7й версией (то есть лет 30 назад) при выставлении соответствующих опций, и развивать его проблема потому, что надо не сломать всё это чёртово легаси. Но за счёт его и сохраняется популярность для энтерпрайза. Например: habr.com/ru/articles/429946
Я не вкапывался, но похоже на правду.
Аналогично то что вы пишете — про работу даже на самом кривом коде запросов — может быть аналогичной целью или даже ею же.

если протокол клиент-сервер то нет, там максимум 2 версии поддерживается, очень прикольно когда есть старый сервак, а клиенту нужны разные базы с разных версий серверов
oraclefact.wordpress.com/...​versions-doc-id-207303-1

еее... я не поняв, пан за оракль чи за мускуль?

прикольна стаття
куча чого рассмотрено но ничого дійсно важливово взагалі не упомянуто

реплікаціі бекапи HA конекшен пулинг рівень супорту в клаудах — вот це все тупо побоку

пограмисти чисто у своєму стили подивились на сінтаксіс та вибирають хз що хз навіщо

Згоден що обирати БД тiльки по розглянутим плюшкам недостатьно. Це тiльки перша частина, бiльш глибше я розгляну в другiй. Просто поспiшив з висновками.

опа, нарешті за айті-айті тема, дяки автору і особливо — змістовним коментаторам!
збергі на почитати-розібратись папізже))

PostgreSQL поступово набирала популярність і лише в останні роки змогла наблизитися до популярності
MySQL

Напевно треба рахувати postgresql vs mysql+maria db.

Цікаво що mysql не підтримує materialised views, це стандартний костиль на старих великих проектах.

mysql все ж таки поки що бiльш популярний, але так я планував трохи розглянути форки percona db та mariadb в другiй статтi.

MySQL ❌
PostgreSQL ❌
TimeScale DB ✅

TimeScale DB це ж timeseries DB, бiльше про збiр метрик. Тому в деяких випадках вона краща, а в деяких не дуже пiдходить. Ну i це ж просто надбудова над Postgresql.

Как-то в контексте оминули колоночные базы, nosql, timeseries, а ведь они на некоторых проектах, где к данным не нужна транзакционность, горизонтально скейлятся очень хорошо и могут на порядки переплюнуть реляционки. Оракл точно мимо, это своя экосистема для жирных интерпрайзов, где кастомеры спокойно могут отвалить за саппорт и лицензии сотни килобаксов

може це тому, що стаття в принципі про порівняння слона й дельфіна? а не про всі можливі типи бд.

Я хотiв порiвняти 2 основнi БД, а про колонкові, nosql та iншi БД можна окрему статтю писати, тому поки без них

Тут я бачу багато фанатів Оракла і багато коментів, навіть не знаю на який відповідати... Тому прокоментую всі.

А потім оце усе забрати в купку, викинути на смітник і поставити нормальний Оракл
є оракл для великих обсягів даних, постгрес на таких навантаженнях ляже тай усе

Чомусь я міграції з Оракла на щось інше бачив, а в зворотному напрямку — ні. Приклади великих систем які використовують Open Source рішення:
— MySQL — Uber, Booking, GitHub, Wikipedia, etc.
— PostgreSQL — Instagram, iTunes, iCloud, Spotify, Reddit, Skype, etc.

Як думаєте, їм доведеться переходити на Оракл, коли об’єм даних стане великим, чи не факт?

бо в оракла краща архітектура
оракл більш стійкий бо там продумана архітектура

Можна детальніше, в чому вона краща? Реально цікаво.

це не головне, я про відмовостійкість до якої іншим скбд як до луни

Щодо надійності в цілому... Я тісно працював з Ораклом між 2006 і 2013 роками. З інтервалом десь в рік чи два зустрів два офіційних патча які в хлам розламували вичитку даних. Це приблизно на два більше ніж у інших СУБД з якими я працював.

Тут вже згадували посилання про культуру розробки ядра Ораклу — news.ycombinator.com/item?id=18442637

А щодо відмовостійкості — крім Оракла більш ніхто не вміє в Highly Available кластери?

звісно це провокативне питання, але я вважаю що «інстумент повинен бути якісним», а наскільки ці ваші бд відсталі порівняно з ораклом — жах

Відсталі в чому? Можна більше деталей без загального «в нього краще архітектура»?

щодо «економії»... у кожного свій досвід але задумайтесь — навіщо економити гроші дяді у якого й так три лексуса :)

Компанії зацікавлені в зменшенні витрат. Як пояснити замовнику на пальцях що мінімум 17500 доларів за процесор на рік + відсоток за сапорт — це необхідність для системи. Пояснення «в нього архітектура краще» не підійде.

І щоб не було непорозуміння — в Оракла є свої сильні сторони, спору нема, але вони вже давно як не безальтернативні. Той же MS SQL в ентерпрайз середовищі — сильний конкурент з багатим набором фіч, і при цьому дешевший. А вартість самого Ораклу і складність його сапорту (що знову ж таки значить «вартість») примушує багато компаній замислитися а за що вони насправді платять і чи не має сенсу позбутися цієї статті витрат.

Тут я бачу багато фанатів Оракла

То вони тролять :)

Хочеться вірити що так, бо в мене дежавю і флешбеки :-)

ви пробачте але писати статтю з порівнянням можливостей — не маю бажання та часу, а з поводу вашого досвіду — ну в кожного він різний, ви «таке» бачили а я «таке»... шо будемо мірятись з лінейкою ? :)

в мене теж був випадок коли оракл сипався на навантаженні з ора-600, я завів ТАР а індус мені каже — «виправимо у наступному релізі» :)

довелось кусок коду переписувати" через сраку" щоб той баг обійти

про культуру розробки ядра Оракл

культура Болівуд.

ні- досить разномамасна команда контрібуторів насправді
жодного с України як не дивно- хотя навідь с нашої перді є двоє
www.postgresql.org/community/contributors

Я для ANTLR портировал грамматику пострескл. Было скучно, я психанул...

Замечу, что фанатов может и много, но цитаты у вас только за авторством нашего минюстовского DBA, который, по собственному признанию, окромя оракла ничего и не знает.
Поэтому подводка так себе.
Что касается того, что для всякой задачи есть свой инструмент — так с этим вроде бы никто (помимо процитированного господина) и не спорил.

На момент моєї відповіді було щонайменше 3 автори схожих коментарів. Наприклад, перший процитований мною комент не від ДБА з мін’юсту. Можливо інші просто тролили, хто їх знає.

окромя оракла ничего и не знает

але я знаю про нього майже ВСЕ :) у цьому й сенс!
програмую, адмініструю та проектую, оптімізую та багато іншого...

я в мінюсті вже 10 років не працюю (СЛАВА ІСУ!!!), але на Оракл завжди є попит ... навіщо мені ваші недолугі СКБД ?

я наприклад одразу купив собі Сеат Леон 2л (який полюбив тільки побачивши його на вулиці перший раз), а не тренувався на запорожці, аналогія зрозуміла?

але я знаю про нього майже ВСЕ :)

Скромняга какой.

«Скромность хороша для посредственностей» © кажись ще Ранєвська казала...

в мене 27 років досвіду з Ораклом то шо ти хочеш?

в мене 27 років досвіду з Ораклом то шо ти хочеш?

Опыт != «знаю почти всё»
всегда есть то, чего ты не знаешь
Єто я как человек, у которого 29 лет опіта со скулём, говорю

Зазвичай категоричність — ознака невігластва, оскільки життя набагато складніше ніж можна собі уявити.

є моменти у яких треба бути категоричним, а не шмарклі жувати, є купа прикладів :)

РІзниця між ними як між рамним кросовером та седаном/сімейним веном, і з опису можливостей зрозуміліше не стане яка краще для конкретного проєкту.

А тому треба дивитись тупо на досвід інших, у подібних проєктах, з подібним типом навантаженням.

Про один плюс вже написали — працювати з My/Maria набагато простіше, як в плані адміністрування, так и розробкі (менше можливостей — менша проблема вибору)

Свої ж коротенькі правила вибору такі:
Якщо у вас не хайлоад, і не планується у самих сміливих мріях власників продукту у наблийжчі рокі — My/Maria
Якщо у вас інтранет ентерпрайз (склади, «бухгалтерія», та інша хитромудра бюрократія), і запити будуть з десятками джойнів, кінцевий SQL на декілька екранів, ..., - то PostgreSQL
Якщо у вас невелика команда «вебмайстрів», фулстеків мідл+ з неглибокими знаннями SQL — My/Maria (все одно не полізуть у PostgreSQL)
Якщо читати з бази будуть набагато більше, і одне й те ж саме, аніж писати в неї — My/Maria, бо переваг PostgreSQL ви не відчуєте.
Якщо для PHP — My/Maria, бо конекти працюють зовсім по іншому, і для типового сценарія роботи з PHP так як треба.

З наведеними кейсами частково погоджуся, тому що навіть не в хайлоаді, можна успішно використовувати postgresql, просто потрібен досвід.
Якщо підходити до вибору більш ретельно, то опис можливостей теж може вплинути на вибір, але це так це не основа.

дякую за порівняння, але особисто мені синтаксичні відмінності між бд при виборі — справа десята, хоча й важлива. Чому ?

Бо по-перше SQL має стандарти і поступово, емпірично всі бд намагаються підтримувати
по-друге відсотків 80+ коду — це або врапери або копіпаст. А в тих 10% де руцями писати SQL — все рівно дивишся документацію, бо зачасту там щось не трівіальне потрібне

А що мене цікавить (з технічної сторони)?
1. легкість створення тестового енвайременту (testcontainer, embedded h2 with dialect, dockers, режими самої бд для тестів — так щоб в hdd не було записів або вона була легко embeddable)
2. CDC/spark/etc — чи підтримує, з якої версії тощо.
3. легкість спригнути — наскільки повно підтримують стандарти, рішення по цьому від AWS etc
4. вибір движків. MyISAM,Aria, InnoDB — чим більше тим краще. Бо інколи ACID must have, а інколи — непотріб, аби швидко віддавали відповідь. По приниципу «скільки буди 5 на 6 — сорок шість — але це ж не правильно — зато швидко»
5. плагіни та розширення — по ним всі пункти з 1 по 7 окремо.
6. по перформансу — потрібно не «швидше» а «ось залежності від розміру » «ось залежності від кількості одночасних підключень» тощо. Хотів було додати особливості реалізаці-підтримки транзакцій саме на стороні СУБД — але не певен, бо всі СУБД розвиваються, сьогодні в одній MVCC вдало реалізовано — завтра в іншій, теж і по перформансу. Колись new thread в Linux OS був дуже дорог — зараз не дуже тощо
7. легкість інтеграції сесюриті. Так щоб тиц-тиц — і віндовс логін з групами/ролями а не ото всьо
8. якщо вже зайшли про SQL — то мені бажано прогнозованість та розширення над базою

Не технічні моменти я опущу

Як я вже нижче писав в комментах, це в мене перша вводна частина, так би мовити показати різні синтаксичні плюшки в обох БД, в другій планую більше заглянути під капот: як працює mvcc у обох бд, які є нюанси з postgresql (типу autovacuum, hot оптимізації...), продуктивність і масштабування...
А що до ваших пунктів, то можу коротенько відповісти:
1. це більше про сторонні інструменти
2. CDC вже давно підтримуюють усі основні БД, в тому числі oracle та mssql, у Debezium э коннектори під усі ці БД
3. тут трохи складніше ніж просто підтримка стандартів sql, якщо починаєшь наповну використовувати БД, а не просто як звичайний CRUD, то потім з будь якої БД важко перейти на іншу.
4. про це планував написати в другій частині статті, а також трохи затронути форки mysql
5. деякі плагіни я трохи затронув у цій статті, але якщо зануритись в них, то можна декілька окремих статей написати, але я не думаю що цей пункт сильно вплине на вибір БД
6. про перформанс планую написати в другій частині
7. про сесюріті згоден, можна було б трохи описати як воно влаштоване в обох БД, але якось упустив цей момент.

Мені так забавно чути доводи про обʼєм БД, що потягне Оракл, та не потягнуть інші — у мене є відразу 2 зауваження. Я особисто бачив для всіх трьох (і ще MSSQL, але там було трохи менше Тб) БД більше кількох Тб, і питання перше — чи багато ви знаєте проектів де реально аж такі обʼєми?

Питання друге, основна перевага БД у використанні транзакцій. І тут цікаво те, що саме транзакційних даних, тобто таблиць на яких виконуються транзакції та де вони реально важливі, серед отих кількох ТБ — скільки?

Бо пихати блоби у БД як у файлову систему, це не ознака розуму, вибачте. Купу разів бачив. Якщо у вас блоби, які не потребують транзакцій — візьміть файлову систему чи документ-орієнтовану базу, що легко шардиться — Mongo/Cassandra/etc і не знущайтеся над собою і залізом.

Я не кажу, що не буває, коли вам всі терабайти треба мати в транзакціях, але вірогідність таке зустріти, ну, скажемо так, не дуже висока. Таких корпорацій (і їх БД) можна перерахувати по пальцях. У більшості випадків ви такі обʼєми або не побачите, або їх можна, навіть треба зберігати не в транзакційній БД.

Колись бачив проект, де сканували паперові документи у PDF і пхали в БД — потім розказували, що серверів не вистачає, не дуже швидко, казали, працює :):):) Треба докупляти... дуже сумно, що залізо докупити можна, а мізки — ні. ;)

проблема в великих БД не в клобах зовсім а в невигластві більшинства розробників

щодо «економії»... у кожного свій досвід але задумайтесь — навіщо економити гроші дяді у якого й так три лексуса :)

щодо «економії»... у кожного свій досвід але задумайтесь — навіщо економити гроші дяді у якого й так три лексуса :)

Ну так це вже не технічне питання і до характеристик чи спроможностей СУБД не має жодного відношення ;)

але задумайтесь — навіщо економити гроші дяді у якого й так три лексуса

Саме тому, що деякі айтишникі не розуміють, чому гроші не ростуть на деревах.
І що прийде хтось до вашого дяді і скаже «я на вашому проекті можу зробити все майже те саме, але дешевше, бо викину оракл і впроваджу маріяДБ».

А потім айтишникі не розуміють, чому сократили третину персоналу і проект переїхав з україни в до індусів.

бувають таки пройопи — що залізом ви нічого не вирішите :)

Як і «архітектурою» СУБД ;)

Щоб обрати базу даних, немає сенсу розглядати такі мінорні деталі як перейменування таблиць, або список стандартних запитів. Важливо інше:
— Які є розширення моделі даних за межами звичайних типів (в тому ж PostgreSQL підтримуються масиви, JSONB, композитні типи, спеціалізоване розширення для тайм серій TimescaleDB та багато чого іншого).
— Які типи індексів підтримуються.
— Як працює блокування — чим більше блокувань, тим гірше БД справляється з частим оновленням.
— В яких сценаріях забезпечується транзакційність, в яких — ні.
— Які є підводні камені реалізації транзакційності (в тому ж PostgreSQL це про vacuum та wraparound).
— Які є публічні бенчмарки, що показують як кожна база себе поводить в різних патернах навантаження на різних об’ємах даних.
— Як забезпечується висока доступність.
— Які способи масштабування підтримуються (наприклад, за допомогою розширення Citus для PostgreSQL можна будувати кластер із шардів).
— Чи є рішення для реалізації zero-downtime schema evolution і чи є якісь підводні камені з цим.
— Які є відомі системи побудовані на тій чи іншій базі. Але тут треба більше деталей, щоби бути об’єктивним. Бо є рішення на тому ж MySQL де від нього, грубо кажучи, тільки назва, а під капотом насправді щось дуже кастомне заточене під конкретну задачу.
...

Якщо є потреба поганяти бенчмарки на різних базах — є моя тула в опенсорсі github.com/...​riyIvon/DatabaseBenchmark (на правах реклами :))

Згоден з вами, що для вибору БД треба проаналізувати багато чого, я й планую в другій частині роздивитися як ці БД працюють під капотом, просто матеріалу багато все в одну статтю не влізло.

то почніть з підручника оракла, тоді на інші скбд ви більш не подивитесь :) рекомендую прочитатти це

OCA /OCP
Oracle Database 11g (новішого щоб скачати не бачив у інеті, але то не важливо)
A ll-in-One
Exam Guide
(Exam 1Z0-051, 1Z0-052, and 1Z0-053)
John Watson
Roopesh Ramklass

Я не працював з Oracle в продi, тому не можу за нього нічого сказати, але помiтив, що ви пропонуєте його у всіх комментах. Жодна БД не являється срібною кулею, тому для різних кейсів можут підходити різні БД. І навіть якщо в якомусь кейсі сподобається oracle, то це не значить, що я не буду розглядати інші БД.
Плюс в нього є великий мінус — це його ціна, яка для середніх компаній, може бути дуже великою.
P.S. ну і глянувши на коммент людини яка там працювала, то жах чесно кажучи news.ycombinator.com/item?id=18442637

я теж багато поганого можу розказати про контори де працював...
а це державні проекти! а не приватна фірма оракл :)

але судити треба по «плодах їх», ця скбд найкраща, а найкраще завжди має високу ціну

проект такого масштабу та ще й з 73 року... під капотом завжди має «скелети у шафі» :) головне як він працює

Так, а якi є кейси, де за домогою oracle можна легко зробити, а цими двома БД не можна або важко? Просто за таку цiну вiн має бути наголову вищий. Плюс багато тех гiгантiв юзають пг або мускул i не бачать в них нiяких проблем.

а він і є на голову вищий

прочтіть шо я вам написав потім вирішите
може й статтю напишете ще порівнюючи архітектуру

Дивний у вас пiдхiд, ви скрiзь пишете, що оракл найкращий, але коли вас просять хоча б один кейс навести де вiн найкращий, то ви просто кидає книжку читати. Невже, ви самi не можете жодного кейсу навести? Чи може ви просто крiм оракла, бiльше нi з чим i не працювали, тому i кейсiв нема. Але як можна тодi казати, що вiн найкращий, якщо ви iнших не бачили, дивно.

підхід простий, бо коли ви прочтете про архутетуру оракла то ви кинете у смітник усі унші скбд... оракл «не заходить» лише лінькуватим, яким требам мати параметр speed = 100 у настройках та й усе

лiнь тут нi при чому, просто бiльшiсть компанiй не потягне цiнника оракла i значить не вийде просто забути про iншi БД, навiть якщо оракл настiльки крутий. Треба пiдходити до вибору враховуючи багато факторiв.

навіщо?

на оракл завжди знайдуться роботодавці, бо з оракла мало хто мігрує, а він майже у всіх банків та держустанов

он просто всегда работал там, где бюджеты не ограничены

як я люблю телепатів с доу... неогранічені, агащаз, на держпідприемстві

Там де треба мати повну інфраструктуру розраховану на дестиріччя експлуатації з SLA, скжімо, 99999 або більше, без постійних плясок з бубном і тикання паличками. Оракл — це ж не тільки 3-4 кілограми дієтического м’яса купа якось там зв’язаних табличок, добре хоч іще хоча б у 2-й нормальній формі, це Sun Microsystem залізо і орігінальна Джава. В купі з підтримкою, це на ентерпрайзах відбиває усі витрати на ліцензії, та підтримку. Це схоже на намагання порівнювати зроблену з гівна і палок на Ардуіно якусь падЄлку, з претензією на якусь автоматику, та ще й модними буквами IoT, з екосистемами Siemens чи Allen Bradley, наприклад, в індастріал.

В усього є своє призначення. Шось призначене для «дома, для сім’ї», а шось для серьозних довгограючих систем. Треба тільки ширше дивитися на речі і не обмежувати собі світогляд просто тому що вася(підставити ДОУ, фейсбук, Реддіт, і т.п.) казав шо воно погане/гарне.

Приклад про «зроблену з гівна і палок на Ардуіно якусь падЄлку» не дуже вдалий, але я розумiю, що десь в великих ентерпрайзах оракл з усим оцим обозом має сенс, але це ж не значить, що його треба скрiзь пхати

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

А хто казав про «усюди пхати Оракл»? Якраз усе навпаки — не треба усюди пхати Ардуіно Мускуль або Постгрес, навіть там де їм не місце. Можна котлован копати лопатою, але будівельники чомусь обирають екскаватор.

На вході вимоги, а на виході рішення на основі бюджету і людей. З цього випливає що рішення може бути з гімна і палок на будь-якій БД!
Тому коли ви пишете про 5ть 9ток, то навіть на AWS зробити рішення на 99,999 дуже сумнівно, в 99,99 ше повірю, а тут ви позиціонуєте що взявши Oracle ви тут же отримаєте 99,999. Не від однієї БД залежить SLA)))
У вас може бути MySQL з декількома користувачами і давати при вдалих обставинах за 10 років 99,9999

мова ж не про цифри

просто той хто має досвід у «кровавому ентерпрайзі» (коли від роботи БД залежить твоє здоров’я) той вибере Оракл :)

просто той хто має досвід у «кровавому ентерпрайзі» (коли від роботи БД залежить твоє здоров’я) той вибере Оракл :)

Отнюдь ©
Немало такого энтерпрайща было мигрировано на скуль.

просто той хто має досвід у «кровавому ентерпрайзі» (коли від роботи БД залежить твоє здоров’я) той вибере Оракл

це коли тебе переконують вибрати Оракл добрим словом і пістолетом?

це коли не працює база яка приносить мільони ти їдеш у ліс копати

Я працював якось для японського NTT. В них 5 дев`яток чи може більше. Чомусь усе на Ораклових (Сановьких) Exadata Database Machine побудовано. Вхід в машзал по відбитку долоні і в спецодязі і спец обуві. Більше кількох годин там витимати неможливо, бо вологість близька до 0%. Цікаво було б почути їх думку з приводу перехожу на Мускуль

Цікаво було б почути їх думку з приводу перехожу на Мускуль

Варум бі и найн? Японці весьма забаніе товарищи, они очень бережно и щепетильно относятся к ресурсам. Собрать такой себе шардинг/рейд на «простіх копеечніх серверах» — и вуаля, всё работает ©
Хрен его знает, конечно, что там у них за задачи были.

NTT це Nippon Telephone & Telegraph )) А дротовий телефон в Японії цілком заміняє паспорт )) В тій базі зберігаються уся дані імператорської сім’ї

Варум бі и найн?

))))

NTT це Nippon Telephone & Telegraph ))

Спасибо, я знаю

В тій базі зберігаються уся дані імператорської сім’ї

По состоянию на 2014 год, в императорском доме Японии насчитывалось 23 человека, включая императора, императрицу, наследного принца Нарухито, принца Акисино и других членов семьи
Это не так много информации, можно обойтись простой экселькой

Спасибо, я знаю

Тоді не розумію в чому сенс продовжувати? ))
Це обладнання що має бути доступним 24/7/365, бо інакше те коммутаційне обладнання, що там використовується, не з’єднає абонетна А з абонентом В, бо наразі усе ж «запрограміровано» на відміну від релейок. ))
Усьому є своє місце, і Оракл з його екосистемою займає свою нішу в якій не має доступу усякому мотлоху. Я вже десь тут писав — котловани для будинків цілком можна копати лопатами, але чомусь будівельні контори обирають екскаватори.

Це обладнання що має бути доступним 24/7/365, бо інакше те коммутаційне обладнання, що там використовується, не з’єднає абонетна А з абонентом В, бо наразі усе ж «запрограміровано» на відміну від релейок. ))

ну и прекрасно. распределенная система легковесного ПО справится с єтим значительно лучше, чем огромный тяжеловесный монстр
а шардинг по облаку инстансов позволит нам избежать ситуации, когда в результате сбоя ложится вся сеть, а не какой-то её сегмент

Усьому є своє місце, і Оракл з його екосистемою займає свою нішу в якій не має доступу усякому мотлоху.

Это заблуждение
как правило (не всегда, но очень часто) «оракл занимает свою нишу» только благодаря тому что перейти на что-то более вмеяемое — это долго и дорого. Хотя и в этой части лет уже как 20 есть определённые крайне положительные сдвиги

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

распределенная система легковесного ПО

і

шардинг по облаку

неможлива законодавчо.

как правило (не всегда, но очень часто) «оракл занимает свою нишу» только благодаря тому что перейти на что-то более вмеяемое

За десятки років я бачив тільки зворотню сітуацію.

неможлива законодавчо.

Ровно до тех пор пока датацентр не нахожитья в Японии
Кроме того, «распределенная система лекговесного ПО» вполне может быть смонтирована в том же машзале, где смонтирован обычный «тяжелый» сервер
Ну и кроме того — есть примеры когда япоские корпорации используют облака (но я не уточнял физическое расположение датацетров, может они в японии)

За десятки років я бачив тільки зворотню сітуацію.

Я наблюдал, как минимум, 3 десятка таких ситуаций, когда контора десятилетиями сидела на оракуле, а на скуль смогла перелезть только когда появилась реальная возможность это сделать.

какие японцы молодцы. Завидую

видать, это что-то очень злое. Exadata стоит как Боинг

видать, это что-то очень злое. Exadata стоит как Боинг

В 50% случаев «оно не надо», покупают потому что «ну, мы большое предприятие — нам надо большое ПО» ©
Хотя в целом для японцев это, конечно, не характерно.
Поразительные жмоты и крохоборы, мне в них это нравится

Оракл обирають не заради згаданих понтів, а заради повної екосистеми, підтримки, і гарантій шо воно проіснує хоча б 20 років. І ви дуже погано знаєте японців і їх менталітет.
Ну і PL/SQL і сторед процедури ніхто не відміняв.

Оракл обирають не заради згаданих понтів, а заради повної екосистеми, підтримки, і гарантій шо воно проіснує хоча б 20 років.

Ну конечно

І ви дуже погано знаєте японців і їх менталітет.

разумеется

Ну і PL/SQL і сторед процедури ніхто не відміняв.

А вот тут я совершенно потерял нить повествования, если честно
причем тут «пл скл и процидуры»?

я совершенно потерял нить повествования

а я с самого початку і не бачив ту «ніть». Бо сам по собі пост і подача, м’яко кажучі, на рівні студента початкових курсів якогсь політеха.

а я с самого початку і не бачив ту «ніть»

ну было бы страно требовать от сишника понимания оракулов и прочей базы данных, а также того как японцы работают :)

также того как японцы работают

Повчіть ще мене щодо японців ))

Надеюсь, местные адепты не подведут и расскажут, как японцам с такой инфраструктурой нужно немедленно переехать в «хмару», чтобы быть, так сказать, «on the edge»

Надеюсь, местные адепты не подведут и расскажут, как японцам с такой инфраструктурой нужно немедленно переехать в «хмару», чтобы быть, так сказать, «on the edge»

Ну, некоторые довольно крупные компании и правда переезжают в облакою Делают они это, конечно, не для того чтобы «быть на острие», а потому что умеют в деньги.

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

Вас не затруднит рассказать, как, допустим, в Postgres’е партиционировать существующую таблицу, не останавливая приложение (в т.ч. работу с этой таблицей как через хранимки так и напрямую)?

Вас не затруднит рассказать, как, допустим, в Postgres’е партиционировать существующую таблицу, не останавливая приложение (в т.ч. работу с этой таблицей как через хранимки так и напрямую)?

А як у Ораклі це зробити?

smthg like
alter table table_name modify partition_clause online update indexes;

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

Можно подробнее? Новая таблица создается с другим именем — как клиенты узнают, что писать нужно уже в неё? И как реализовывается работа со старыми данными (их модификация, или запросы, которые обрабатывают данные из этих двух таблиц одновременно)?

тітани постгреса та мускула над такими задачами навіть не замислюються, у них «усе просто» та «все у хмарі саме робиться»

думаю, ключевое

у хмарі

. А там все равно — хоть PostgreSQL, хоть Oracle, хоть неупомянутый нигде втопике Informix

Ніт. В клауд версиях деякий функціонал може не працювати, або працювати з обмеженнями

це все гарно до першого випадку коли «все не працює» а у відповідь раджеш тобі каже — читайте сноску номер 12345 там написано шо ми ні за шо не відповідаємо...

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

це на продакшені у «гарячі часи» ви такє зробите??? ахахахахах

я присутствовал на этом процессе, как ответственный за некоторые сервисы, потом полетели высокие бошки на улицу за подобные миграции, то что прод помер на полсуток и было утрачен весь доход за это время, то что модель бизнеса была типа pay per click

А разве всякая версия Oracle такое чудо поддерживает?

В каком смысле «всякая»? Если я не ошибаюсь, начиная с 12.2, что как бы уже довольно древняя версия.

Oracle Partitioning is exclusively available with the Oracle Database Enterprise Edition (DBEE). Organizations must acquire an Enterprise Edition license to license and use the partitioning feature.

але судити треба по «плодах їх», ця скбд найкраща, а найкраще завжди має високу ціну

Гівно мамонта, а не найкраща вона.
Уже 13 років не стикався з нею ні в коммерційній розробці, ні в ентерпрайзі ні в технологічних трендах. Її продовжують використовувати в ентерпрайзі там де легше заплатити за дорогі ліцензії і саппорт великій компанії з якої можна зрубити бабло в судах у випадку проблем і задрочувати саппорт питаннями, якщо не зрозуміло що не працює. Продають в основному її разом з різним коборочним ентерпрайз софтом там де легше відкати пилити за коммерційні закриті рішення де первинна не ефективність технологічна, а розпил бабла, і там де стеля технологічних рішень це тюнити сіквел квері. Мій досвід з ораклом це корпоративний жах, явно не кращий в плані вирішення технологічних проблем. спробуй знайти хоч одну reference архітектуру від технологічних компаній або науковий paper де буде фігурувати oracle rdbms — хєр там.

якщо пропустити ваш словісний пронос, то скажіть шо краще як скбд?

Pg/mysql краще — вам не це вже не один раз вказали.

більше питань не маю

-чим кращий?
-чим оракл!

в моєму кейсі sqlite найкращий. Чи influx

карманна бд на мобілці? ну ок

мій ментор Сергій Стеценко (найкращий спец по ораклу що я знав! та має «талант викладача» 80 левел) казав ще про мускул — «Я люблю прокатиться по лесу утром на велосипеде, но для угольного карьера я выберу карьерный екскаватор» :)

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

он так не умеет. у него все проекты с баджетом не меньше 500К только на лицензии.

я зараз взагалі б не радив по лісу кататись, бо може бути заміновано

якщо ви мене розуміете ...

де стеля технологічних рішень це тюнити сіквел квері

А з цим що не так? Чи замiсть тюнiнга запиту будемо робити круглi оченята i вимагати премiум-хмару цiною у Боiнг?

та ні, найдемо роботу через дорогу +500 :)

типічна поведінка ефективного мендеждера. Підписати на оракил чергову держустанову і уйти в туман

мені вам потрібно підіймати табличку «сарказм» чи що?

підніміть, да. Тіко текстом до себе поверніть

в мене для вас трохи інша пропозиція та боюсь забанять :)

На мою думку в порівнянні реляційних БД один із важливіших критеріїв — це транзакційність. Було б дуже добре, якщо в темі роботи транзакцій ще й розглянути Race Condition в порівняні цих БД. Тема транзакцій серйозна і в той же час гаряча та палка)))

хоч постгрес, хоч mysql, аби не, прости господи, mongodb)

Он вище пхали Джейсон в базу реляційну.
І навпаки можуть джойнт на монго пиляти

Дурь людська безмежна

так а монго хіба може сказати «ти дурний, я в тебе ставитись не буду» =)

— все плюс-мінус норм, доки не треба джойнити. А джойнити, рано чи пізно, виявляється що треба
— незграбний ObjectId замість нормального primary key
— запити класно писати поки працюєш на nodejs. на інших мовах виходить збочення — по факту ми збираємо JS

це те що згадав зі старту, вже більше року з монгою не працюю.

Рішення проблеми джойнів single table design

а потім виходять роздуті колекції такого масштабу, що на кожен запит треба писати гігантський projection, інакше по памʼяті вилітати будеш

А джойнити, рано чи пізно, виявляється що треба

Ну не виявляється.
В нам проект, де є і оракл і постгрес і монго і mssql і S3. І користуються іноді одночасно, навіть в одному компоненті.

так ви ж самі сказали — є декілька різних баз) а уявіть що у вас є тільки монга

Так ми ж монгу ораклом не заміняємо, де треба монго — там монго, де треба оракл — там оракл

join якщо у вас є у монгі- ви плохо читали документацію та зробили якусь ересь
не треба так робити

це ви зря так, бо mongodb теж має право на життя, просто кожний інструмент треба підбирати з розумом до проекту.

у mongodb є timeseries collections які на timeseries данних отдеруть що mssql що слона як попало
вибирати базу по релігіі а не по типу нагрузки — дурь

MySQL використовують не тому що «звикли» а тому що з ним менше головної болі і більша частина світових проектів не потребуе прям рокет саенсу з базами.

Зрозуміло якшо все складно то вже буде окрема людина, котра відповідае тільки і тільки за базу і тоді використовують слона. Розробники пишуть код, людина слідкуе за тим щоб база правильно і оптимально працювала.

Вангую набігуть адепти «PostgreSQL це просто» але по факту MySQL це як php світу баз. Криве, урізане — але просте, виконуе свою задачу і не потребуе знання цілої купи ритуалів під кожен випадок.
Із моеї практики колупався з різними базами, е цікаві рішеня, е прям круті рішення. Но потім повертаешся до проектів, котрі повинні бути підтримувані ше довго і розуміеш що 99% «фіч» не потрібні, а ше вони одразу рубають можливість швидко змінити базу якшо потрібно (проект виріс).
Коли для задачі критично важливий якийсь функціонал БД, котрого нема в інших БД — або у вас дуже великий і складний проект, сотні розробників і окремі архітектори для БД і всі сказали шо так, без цього не обійтись; або у вас неправильно побудован сам проект із-за чого і виникла такая «прив’язка»

Взагалі якщо б оракл чи постргес були б «срібною пулею» не виникло би причин розробляти безліч інших видів баз данних. Тільки відкритих на гітхабі під сотню, а якщо дивитись в цілому (навіть забувши про векторні для нейронок) то можна побачити що мусул та посгресс це вже минуле, як по процессам (швидкість, об’ем) так і по задачам (шардування, консистенсість)

По першій частині згоден, що mysql використовують, бо він тупо простіше.

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

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

На зараз шардування та консистенсніть між нодами вирішуеться сторонніми рішенями. Самі кращі на ринку платні написані з нуля.
Основні задачі це швидкість та доступність в рамках конкретного географічного положння. На другому місці пошук та виборка по конкретному індексу.

Найбільш популярні рішеня це TiDB і тому подібне коли в основі існуюча реляційна база данних, але такі рішеня не такі оптимальні як написані під конкретно цю задачу

За об’ем також — те шо постгрес вміщуе терабайти не означае шо він нормально горизонтально маштабуеться шоб віддавати мільярдам користувачам одночасно

На зараз шардування та консистенсніть між нодами вирішуеться сторонніми рішенями. Самі кращі на ринку платні написані з нуля.

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

Основні задачі це швидкість та доступність в рамках конкретного географічного положння

Знову ж таки все залежить від потреб, але в мене в більшості випадків консистентність була одним з найважливіших факторів.

За об’ем також — те шо постгрес вміщуе терабайти не означае шо він нормально горизонтально маштабуеться шоб віддавати мільярдам користувачам одночасно

А у вас є приклади, коли постгрес не міг нормально масштабуватись на великих даних?

може запізно але не бачив сповіщення, Dou дуже кривий портал як для «IT-хабу»))

А у вас є приклади, коли постгрес не міг нормально масштабуватись на великих даних?

Безліч, не не питання бази, це питання тонкого місця. Горизонтально масштабуються проще (з точки зору бізнесу) чим вертикально. Плюс горизонтальна реплікація знижуе потреби до коду та розробників, в вертикально ж треба вміти писати код під 100КK/s.
І найголовніше — горизонтальне більш стійке до збоїв які не залежать від бізнесу (ідіотизм розробки коли невдалий реліз все кладе це сторона бізнесу).

В цілому я не спеціаліст баз, я скоріш спеціаліст систем. Працював з усіма популярними базами (і з безліч непопулярними, особливо з новими векторними).
З моеї точки зору точка відповідності БД не повинна бути великою в системі в цілому. Навіть з точки зору швидкодії бази додають макс 20%, і то тільки в випадках коли потрібно «хуяк і в продакшен» тому юзають готові механізми в базі (і саме для такого вибирають конкретну базу).
В інших випадках всі ці «фішки» з трассуванням ключів в json чи стисканням на стороні бази конкретніх колонок із світу «фреймворків».
Що реально важливо так це індексація та пошук по індексам. Ті самі геомітки (і пошук по ним векторно) особливо якщо у вас весь світ (з Китаєм де своя навігація) або банальніший пошук по часу чи числовим рядам. На третьому місці пошук по індексам з фіксованим розміром (hash-id) і з цим зараз взагалі не все так добре як хотілось би (майже у всіх е підтримка UID але це всього 16 байт і кажна база працюе з ними як вважае за потрібне, інколи «краше» працювати як з простим записом чим як з UID)

Навіть з точки зору швидкодії бази додають макс 20%,

пардон, а хто тоді дає 80% гальмування?
я думав це зазвичай FULLSCAN по таблиці під 200Гб...

Чи є якісь посилання на бенчмарки що підтверджують що MySQL швидше читає?
Висновок про легкість налаштування базується чисто на складнощах з PostGIS?
Вся стаття це або «обидві бази вміють це» або «PostgreSQL вміє трошки більше/краще».
Люди продовжують використовувати MySQL чисто по звичці.

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

проблема слоника не в вакууме ....
подводные камни прячутся в парадигме мульверсионной БД
то есть длительная незакрытая транзакция при интенсивном потоке записи приводит к раздуванию БД на диске. Порой — очень большому. Вот за этим надо следить/настраивать и так далее. В остальном — слоник персик !

а в мускулі хіба не дується журнал? тю.

вакуум — це просто символ. означення ситуації «а от я чув, що...».
Так то постгре прикольний, да. partial індекси, кастомні типи, транзакційний ddl. Свого часу спілкувався з хлопцями, у котрих дані від сенсорів голий постгрес приймав, мінімально опрацьовував і зберігав. І їм було норм.

це працює якщо у вас реально мало данних та сенсорів
кажу як людина трохи бачившая сенсори

Timescale ніби обробив постгрес напильником щоб туди пхати сенсори — і на цьому робить гроші.

Timescale та просто слоник це дві велики різниці.
Тут про звичайний постгрес казали, а це прямо кажучи поганий вибір для timeseries data

Той же mongo db time series collections ще є якщо не хочеться спеціалізовану базу

Чи є якісь посилання на бенчмарки що підтверджують що MySQL швидше читає?

наразі я не проводив замірів, але із-за того що mysql простіший в використанні, то він може вигравати по швидкості на великих постійно оновлюванних таблицях, бо в нього по іншому розроблений MVCC.

Висновок про легкість налаштування базується чисто на складнощах з PostGIS?

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

Вся стаття це або «обидві бази вміють це» або «PostgreSQL вміє трошки більше/краще».

я хотів показати що вміють обидві БД, але грішу тим, що я фанат postgresql, тому може із-за цього так і вийшло.

Люди продовжують використовувати MySQL чисто по звичці.

тут згоден, що багато хто не замислюеться з вибором, якщо вже звик до якоїсь БД.

то він може вигравати по швидкості на великих постійно оновлюванних таблицях, бо в нього по іншому розроблений MVCC

то в постгрeсi «по іншому розроблений MVCC», бо нi в Ораклi, нi в MsSql нe чув щоб постiйно боролись з вакуумум на таблицях з iнтeнсивними апдeйтами. Алe HOT сподiваюсь всe ж виправив цю проблeму (?).

Реалізація MVCC postgresql ближча до оригінального стандарту (en.wikipedia.org/...​rsion_concurrency_control), тому що зберігає старі версії рядків в основному сховищі (я не кажу що це краща реалізація, але вона ближча до оригіналу), тоді як mysql зберігає старі версії окремо в спеціальній області пам’яті undo tablespace (це вважається модифікованим механізмом mvcc). Так само і у oracle і mssql свої реалізації.
HOT вирішує частину проблем, але, на жаль, не всі його знають і вміють використовувати.

Реалізація mvcc може і ближче до оригінального стандарту, але дуже довго це було однією з найбільших проблем постгресу при інтенсивних апдейтах. По HOT сподобалась табличка в пості stackoverflow.com/...​ate-tables-in-postgres-13 , правда там всього лише 2.5к апдейтів, небагато, але видно що сама ідея працює.

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

Цiкаво, почитав би про практичний досвiд. Бо сам з постгрe пiд сeрьойзним навантажeнням нe працював.

А один з mysql сeрвeрiв робить за добу 300M+ (мiльйонiв) апдeйтiв, трохи мeньшe iнсeртiв i в рази бiльшe ceлeктiв. Коли налаштування початковi зробив — воно просто працює бeз втручання (поки нe пролiзe якийсь новий нeоптимальний sql). Звiсно що 99.9% цe досить простi oltp запити, бeз джойнiв на купу таблиць та iншe, алe данних тeрабайти.

Щe в постргeсi трохи лякає 32-х бiтний каунтeр транзакцiй, бо якщо за добу наприклад мiльярд транзакцiй, i вакуум почнe тупити, то часу нe так багато щоб розiбратись пока всe нe встанe.

Ну тобто практичний досвiд цiкавий, а то зрозумiло що постгрeс бiльш функцiональний, нeпогано розвивається i думаю за ним майбутнє. Алe коли нe трeба складного функцiоналу, то i mysql щось трохи можe.

Я не думаю, що багато чого зможу описати з практичної точки та чимось вас здивувати, тому що мiй досвiд з хайлоадом був десь рокiв 5 назад, а зараз я працюю з невеликими об’ємами.

Щe в постргeсi трохи лякає 32-х бiтний каунтeр транзакцiй, бо якщо за добу наприклад мiльярд транзакцiй, i вакуум почнe тупити, то часу нe так багато щоб розiбратись пока всe нe встанe.

це називається «немасштабуєме рішення»

до речі що там так апдейтять ?
зазвичай важливим даним ставлять «признак чи дату закриття» а не апдейтять, це більш корисно потім :)

це називається «немасштабуєме рішення»

є форк Postgres Pro Enterprise (наче російський) де цей лічильник 64bit і патч який намагаються в основне ядро пропихнути, але щось воно не рухається.

Цікава стаття (російською)
habr.com/...​tgrespro/articles/864142

до речі що там так апдейтять ?

біткойни майнимо в базі :)

коли проект якась суміш ad + fin tech, то данних може бути багато, періодично частина логіки переводиться на черги, чи redis щоб в базу записувати вже агреговані дані хоча б раз в хвилину, але то вічна бороться — щось винесли з бази, але новий функціонал додали, то ті 8-9K апдейтів в секунду в пікові години так завжди і тримаються (хм, раніше наче було більше, все ж таки боремся). В принципі не важливо що, головне сам proof of concept що це можливо і працює в проді не один рік.

Цікава стаття (російською)
habr.com/...​tgrespro/articles/864142

прочитав, дякую
ні, такий футбол нам не потрібен ©

бачите а в ораклі я навіть таких проблем не чув
стрічки за блок бд вилазять чи що?
що за вакуум? пусті записи? в блоках пусто?

коли постгрес робить апдейт, від додає повну копію рядка, навіть якщо оновили поле на 1 байт, а якщо є ще поле json на мегабайт, яке не міняли, то постгрес все одно і його продублює. Зробили 1000 апдейтів одного рядка, маємо 1000 повних копій. І це не лише займає місце на диску, раніше (зараз все краще) щоб отримати данні по цьому рядку, постгрес читав цю тишу старих версій поки не знайде актуальну. Просідав перфоманс на читання, також якщо є індекси, а вони майже завжди є, то треба їх оновлювати, навіть якщо помінялись не індексе поле. На цю тему uber писав, як на одну з причин міграції на mysql з постгресу.

А ось процесс який чистить старі данні, то і є цей вакуум.

господі який жах :)
він шо не в буферному кеші блоки апдейтить?
бо оракл апдейтить блоками, це перевага номер 1

В oracle натомість бояться зі Snapshot too old :)

считані рази таке бачив, треба правильно проектувати

звісно це провокативне питання, але я вважаю що «інстумент повинен бути якісним», а наскільки ці ваші бд відсталі порівняно з ораклом — жах ..

Так убедите автора, что бесплатная версия Oracle(с вагоном ограничений) лучше чем слоник.
без болтовни — просто 3 примеру которые лично ваши задачи решил Oracle но не решил Postgresql. Причем желательно не вспоминать события 20-й летней давности

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

якщо ви взагалі не економите на ресурсах, то це вже погано пахне.

ну ваша контора точно шо «економить», на єйчарах :)
на одну вакансію зі мною зв’язалось 4 людини і ні одна не дала фідбеку до сих пір (2 міс)... огидно навіть працювати у таких конторах

моя контора з вами точно справ не мала, бо я фоп

чому тоді там у вас написано про люксофт?

бо з ним контракт. Але я не володар, щоб ви до мене претензії висовували

та Боже упаси, так, до слова прийшлося... бо такого мудацького відношення до людей я ще не бачив!

Сам Люксофт нейтральна штука. зп вчасно, страховка є, проблем з налоговою нема. Як бодішоп — не краще але і не поганіше за інших.

А те, що не зв’язались, то це ви дуже прискіпливі. Називати за це мудаками... Може ви внє палітики і не бачіте хто такі справжні мудаки...

то не мудакі а підари, якщо ви про кацапів

я не «прискіпливий», але вважаю якщо єйчар не дає фідбеку то аматорство а не робота

а в них я так розумію УСІ так працюють бо жодна нічого не відповіла...

Фідбек, наскільки я знаю, дають тільки після тех.інтервью, а не просто після зв’язку.
В кожної контори можуть бути своі правила, та й нема такого як «обов’язок надавати фідбек». Можно написати та запитати чи чекати на фідбек.

а я писав... та ладно хер з ними

ти диви, відразу відписалось трое єйчарок :) читають доу чи то ви пнули?

не я, я ж просто фоп на контракті, не штатний співробітник, Я і свого HR вже забув

“інстумент повинен бути якісним”

Note:
Oracle Database currently treats a character value with a length of zero as null.

шо? розвиньте думку бо я шось не пойняв ваших претензій до налла

система настільки якісна, шо каже нам чєловєчєським язиком «я зараз пусті строки як нул сприймаю, але не закладайтеся на це, бо може я передумаю»
але ’’ = ’’ працює не як null = null
карочі в цій «якісній системі» легасі костилів не менше, ніж деінде

це не головне, я про відмовостійкість до якої іншим скбд як до луни

так цей. Звідки вам знати, ви ж нічого іншого на’ть не розглядали ніколи?

я використовую мускуль і за надцять років роботи він зламався у мене один раз. На локальному компі побився файл. Крім цього жодного разу проблем не було. вимкнення елекртики, kill −9, systemctl stop docker — нічого з цього не закораптило у мене ніразу.

а у вас там 20000 конектів одночасно було?

ноу, навіщо мені двадцять тисяч одночасних конектів? В нормальних бд є пули конектів і не треба для кожного чиха заново з’єднуватися.

не доколупуйтесь до слів, ви мене зрозуміли

ніт. я
1. не приколупувався до слів.
2. якщо слова не те, чим кажуцця, то я не зрозумів.

>

а у вас там 20000 конектів одночасно було?

Розкажіть детальніше

якщо у вас одночасно потребує ресурсу бд 20тис кліентів, то ви хоч 4 пула зробіть але вони нікуди не щезнуть, бо пул то про балансировку навантаження а не про відмовостійкисть та швидкість

А якщо не потребує?

а ви на перспективу думайте

про пул то я казав, то інша гілка. Тут запитали про саму ситуацію з двадцятьма тисячами коннектів. Дійсно цікаво де таке у вас було. Бо ми шо, ми на звичайних настільних бд, а не на ентерпрайз левел «якісно зроблених» субд.

так, було в мене таке на державному реєстрі, я навіть інстанс перевів у shared server mode тоді

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

не витягне, там архітектура під карманну бд

навіщо мені сто баз з мускулом замість одного оракла???

один інстанс оракла на залізі за «всі гроші», чи сто інстансів (не баз) мускула за «всі гроші мінус вартість ліцензій оракла». Тож зачим платити більше?

Але я казав не про це. А про те, що необхідність тримати 20000 одночасних коннектів це архітектурна задача, а не обмеження сервера. Серверу дай ресурсів — він триматиме. і мускуль і постргес.
Той же postgres, з командою якого я колись спілкувався, стирчав портами назовні і записував постійний потік даниз з кількох тисяч сенсорів (жпс трекери, датчики). двадцяти тисяч там не було, але кілька сотень rps було і все це працювало на звичайному сервері.

Тож зачим платити більше?

щоб не мати довічного гемору з реплікацієй даних та розподіленими транзакціями

мені — ні до чого, але ж людям працювати потрібно

Ну так є люди які з aws lambda чи azure function намагаються конектитись до бази, звісно що ніяка база не витримає стільки конектів при хорошому лоаді.
Якщо вам треба 20 к конектів у вас щось неправильно в архітектурі.
Ви чули дзвін та не знаєте де він.

замініть слово «конекти» словом «кліенти», не будьте занудою

Е ні, конекти сильно не дорівнюють клієнтам (хіба що ви для кожного юзера тримаєте відкритий конекшн).
Якщо б ви одразу про клієнтів сказали, ні в кого питань би не виникло.

У мене було, і що? Тюниться мережевий стек. Колись обслуговував MySQL на 2Тб даних (там якщо не помиляюсь, чи то 64 ти то 128Гб оперативки було), високонавантажену, з реплікацією на кілька слейвів (причому на частину — повну, на частину — часткову, не всі таблиці, і це все через кілька мережевих інтерфейсів, бо гігабіту не вистачало для всього), політ — нормальний.

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

Взагалі, якщо так вже порівнювати, суто за навантаженням та обʼємом даних — всі три працюють допоки ОС витримує навантаження. І до одиниць терабайт обʼєму — точно кожна потягне без особливих налаштувань типу перекомпіляції чи щось такого.

Тут питання чи багато в світі, хоч за відсотками, хоч абсолютно, таких проектів/БД, щоб не вистачало гігабіту чи вище по трафіку та кількох Терабайт за обʼємом?

до чого тут мережа взагалі? ви хочете у чергу ставити запити? вас кліенти нах одразу пошлють з таким ПЗ

До чого тут черга? Ви маєте на увазі одночасні транзакції? Чи конекти?

не тільки транзакції, селект, виклик функціі і тп...

Гаразд, і? 20к одночасних запитів? Ну так будь-яка з трьох це потягне, аби залізо дозволило.

потягне? 100% ?

навіть я б так не написав не знаючи ні структури данихї ні запитів і тп...

Ну, тобто Оракл потягне в не залежності від структури, а всі інші — в залежності? ;)

Кривими руцями та запитами покласти можна будь-що.

оракл більш стійкий бо там продумана архітектура

Конкретні приклади, коли Оракл витримує, а інші — ні, саме за рахунок архітектури?

news.ycombinator.com/item?id=18442637

яке шикарне посилання.
Все так.

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

mysql i 20k одночасних конeктiв тримає, на гарному залiзi, звичайно. Головнe що конeкти роблять, якi запити, вiд цього основнe навантажeння.

ну я мав на увазі саме запити або виклики, а не фізичні конекти бо сам конект якщо у вас shared server то не є проблема

Практично завжди обирайте

PostgreSQL

. Рівень входу трішки складніший, але потім Ви не будете жалкувати.

я, як фанат postgresql, погоджуся з вами)
Але не завжди людям вистачає експертності нормально працювати з нею, тому потім і виходить, що postgresql поганий, mysql краще.

Покажіть мені компанію, яка в 2024 році використовує MyISAM, мені вже смішно про нього читати в таких статтях. Движок перестали використовувати ще до того як я перші рядки коду написав.

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

яки ще «сценарії»?
є оракл для великих обсягів даних, постгрес на таких навантаженнях ляже тай усе, бо в оракла краща архітектура

Які обсяги даних? Для яких запитів? Для якої кількості користувачів? А може вам взагалі SQL не потрібен, бо у вас якийсь додаток для подкастів на 5 млн. користувачів? Але, я так розумію, тут краще все одно Oracle поставити?☺️

а як ви без реляційної бд будете дані обробляти?

подкасти просто йдуть саме в /dev/null

Я користуюся sqlite для свого телеграм бота. Навіщо мені тут оракл зі своєю кращою архітектурою?
Чому ви всюди мікроскопом цвяхи забиваєте?

«для людини з молотком все навколо — цвяхи» (ц)

Коли працював з Geospatial, то використовував MyISAM, але це було у 2010му

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

Пару років тому мав такий проєкт, треба було багато писати без ключів і транзакцій, свідомо вибрав MyISAM

Він же ламається, якщо є конкурентні insert/updated і в цей час сервер незаплановано уходить в shutdown, то потім такі таблиці майже завжди недоступні і треба запускати mysqlcheck repair, бо зламались індекси.

З переходом на ssd чи навіть коли hhd але з innodb_flush_log_at_trx_commit=0/2 (це вже чіти, алеж), тисячі інсертів на секунду mysql пише і в innodb.

незаплановано уходить в shutdown,

я в каких-то дистрибутивах вроде в калечной убунте, видел крон джобу при старте которая делает принудительный mysqlcheck по всем таблицам чтоб админ руками не лазил)

Каким образом убунта в принципе знает про mysql?
То, что есть скрипт, никаким образом к дистрибутиву ОС отношения не имеет.

Если кто-то руками такой скрипт прикрутил, или его прикрутил сам mysql (и именно для дистрибутива убунты), то это проблема кривых рук

Убунту нe знаeт, но могут быть свои дополнитeльныe скрипты, eсли ставить нe чистую вeрсию с сайта mysql/mariadb, а просто чeрeз apt-get

И это ж нe плохо, ну пусть оно запустится и само чeкнeт, а нe лeжит и алeрты шлёт пока руками что-то нe сдeлаeшь. Кстати ошибся, нe mysqlcheck, а myisamchk, всe эти «Table was marked as crashed and should be repaired», бррр.

А потім оце усе забрати в купку, викинути на смітник і поставити нормальний Оракл ))

Набiгли оракловоди)
Десь oracle може бути кращим вибором, а десь mysql чи postgresql, все залежить від кейсів.

вийде так що ваша база розростеться і ви потім будете мігрувати на оракл :)

І кормушка наступній хвилі розпилювачів бюджету

це суперечливий момент, я свого часу працював з досить великими об’ємами даних і мене влаштовувала postgresql у всіх аспектах. Але кожному своє :)

Скоріше на SingleStore, котрий сумісний з MySQL.

Я дві системи з оракула вашого переписував на інші бази. І ні одної на оракл. Як згадаю танці з бубном навколо того мастодонта так здригнуся.

ви шо саме там на дотнеті писали в ораклі? там plsql або джава унутрях
яки саме танці?

Переписував з оракла, бо в 15 році не було актив-актив реплікації, а клієнт хотів 2 регіони. Другий клієнт не хотів платити 200 штук за ліцензії.
Біль — треба писати процедури на кожен чих. Навіть автоінкременту не було коли я його колупав. Це настільки здивувало що до сих пір пам’ятаю. Хочеш щось складніше за елементарний селект — пиши процедуру, бо вся логіка в пл-сіквел. Оракл тулс прибиті гвіздками до версії серверу, хочеш коннект в інстанс іншої версії — став нові тулси. Хочеш докер для локальної розробки — удачі хлопче, серйозна компанія таке не робить, тому докеру пара років а у нас родмап до двадцятого розписано. Все вищесказане відноситься до версій 12-14 років плюс-мінус. Може зараз воно краще, але я сумніваюсь.

бо в 15 році не було актив-актив реплікації, а клієнт хотів 2 регіони

шо саме ви маете на увазі?
бо в оракла реплікація та розподілені транзакції були ще з 8 версії

2 сервера, райти з кожного регіону ідуть на свій сервер, воно синхронізує в обидва боки. Наче голденгейт у вас то зветься, але воно релізнулося 21 року

ну тобто у вас була одна настандартна задача (такого функціоналу не було в жодній бд як я розумію) і попався один жлоб, який краще купить третій лексус але з’економить на пз та зарплатні... :)
вважаю ваш досвід нерелевантним

Ні, звісно жодна ДБ не випереджає оракл і тоді ми не ввімкнули в мс сіквелі мультімастер і воно не завелося без геморою. Та й працювати на жлобів, які жмуть 200 штук на рік на «надійність» то не релевантно, згоден.
Звісно бути фанатом дефолтного вибору пізніх 90-х не наводячи жодних об’єктивних метрик краще. Виросте база-зрозумію, що краще нічого нема.

якийсь потік свідомості... увольте

Тоді і виник мемасік
Взяли на роботу Java програмістом, але писати треба на Pl/Sql

Біль — треба писати процедури на кожен чих. Навіть автоінкременту не було коли я його колупав

шо значить на кожен чих? е селекти, а є процедурна мова... як ви хотіли?
інкремент там через сіквенси робився (default seq.nextval на стовпці), зара можна на таблиці проставити клаузу інкременту

е селекти, а є процедурна мова... як ви хотіли

Кстати, весьма спорное решение, до сих пор для меня остающееся одной большой загадкой. В MS SQL Server сумели обойтись одним T-SQL, на котором пишутся и селекты,и серверная логика

у Ораклі так само, пишете шо хочете... хоч запит хоч анонімний блок хоч процедуру хоч пакет і тп

SQL це мова «запитів», стандарт є, шо ви хочете не розумію...

мікрософт мені не приклад, в них 80% рішень щодо юзабіліті ідіотські з моєї точки зору

мікрософт мені не приклад, в них 80% рішень щодо юзабіліті ідіотські з моєї точки зору

А ну раскажи мне, как в оракуле не по идиотски сделано различие PL и SQL?
так что у них и типі данніх разніе, и прочие преєлести?

я не понял нічого

єто потому что у вас опіт в оракуле 27 лет и ві всё про него знаете.

ви сударь уви скатились на хамство
типово для кацапа

ви сударь уви скатились на хамство
типово для кацапа

Отнюдь.
А вот ваше скатівание на хамство — типично для балалая, которого поймали на хвастовстве и непрофессионализме, и которій пітается неуклюже съехать с темы

шо отнюдь?

ти принципово пишеш кацапською, то хто ти?

ти принципово пишеш кацапською

Чойто «принципово»? Просто пишу на том языке, на котором мне удобно и который допустим в данной ситуации
Я так понимаю, раз ты пытаешься развязать языкосрачь — ты уже полностью слился и тебя можно со спокойной душой слать на*** и игнорировать, по теме от тебя больше ничего слышно не будет?

справа не у срачі, а у том шо на 3 році війни є ідіоти яким «удобно» та «не зрозуміло» що за срасійською мовою їдуть танки...

про що я маю дискутувати з підкацапником?

ігноруй, я прям спати не буду

справа не у срачі, а у том шо на 3 році війни є ідіоти яким «удобно» та «не зрозуміло» що за срасійською мовою їдуть танки...

С удовольствием подискутрию с вами на єту тему в профильном топике
А вот в топике про мускул и прочее єтому не особо место.
Короче, склифосовский. Не в состоянии дискутировать на проф тему — свали в туман и не отсвечивай

ти ж хотів ігнорувати?
бугага

діскутувати з кацапом мені нема про що, звали сам, це моя країна

ти ж хотів ігнорувати?
бугага

діскутувати з кацапом мені нема про що, звали сам, це моя країна

Совсем, бедолашный, ебанулся.

типово для кацапа

Что характерно, пациент до 2022 общался на русском :)

поціент твій папа...

бачу ти навіть у профіль поліз щоб обісрати :))

а я здатний зрозуміти що таке рідна мова, хоч і пізно, а таки як ти кацапорили — ніколи!

Что характерно, пациент до 2022 общался на русском :)

Ну, это нормально
2022 год многим показал — кто кому рабинович, и даже те, кто до этого «принципиально говорили по руски» — стали говорить по украински.
«Вы не видели красоты — пока вам не показали уродство» ©

Это называется переобувание. But well, не предмет этой темы.

переформулирую: в чем необходимость отдельного Oracle SQL и Oracle PL/SQL с точки зрения прикладного разработчика? Почему varchar2 в PL/SQL и SQL по умолчанию имеют разный размер и нужны дополнительные телодвижения. Для char даже нет этих телодвижений, просто различный допустимый размер. Ссылка docs.oracle.com/...​0B-4AAC-8323-FEB2ED0225D0

переформулюю у чому з точки зору прикладного розробника необхідність розділення Oracle SQL та Oracle PL/SQL
чому за замовчуванням varchar2 у SQLта PL/SQL має різний розмір docs.oracle.com/...​0B-4AAC-8323-FEB2ED0225D0
достатньо чи ще написати англiйською?

дякую

ви англієць?
якщо ні то не треба мені англійської, я нашіх англомовних снобів на дух не переношу :)

бо я наче на українському ресурсі а повинен читати кацапорили висери від кожного другого...

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

щодо ваших питань то тим я ніколи не переймався, та не бачу ніяких проблем

якщо у вас таки проблеми з обмеженням довжини VARCHAR2 пишіть у CLOB та користуйтесь не LISTAGG наприклад, а пакетом XML я хз, що вам там так муляє з тим VARCHAR2... чи ви знайшли «щось» шоб довести шо Оракл гівно? :)

У Оракла гівно — це усе його погане ПЗ (окрім СКБД)

якщо у вас таки проблеми з обмеженням довжини VARCHAR2 пишіть у CLOB та користуйтесь не LISTAGG наприклад, а пакетом XML я хз, що вам там так муляє з тим VARCHAR2...

Человек, который «27 лет на оракуле и знает о нем всё» — по идее должен знать о таких нюансах
Вы, почему-то, не знаете.
Причем я бы вполне принял за ответ (изначальный) что-то типа «ну да, там различия и частичная несовместимость в типах и вообще две разные подсистемы, но даже не смотря на такой бардак и накладные расходы оракул всё равно всех порвёт»
но вы такого не сказали. Хотя, по идее, должны. 27 лет всё таки.
или сколько там у вас «было»

я бы еще добавил, что одна из основных особенностей Oracle — его «особый путь» во многих концепциях и операциях.

я бы еще добавил, что одна из основных особенностей Oracle — его «особый путь» во многих концепциях и операциях.

Это да. Терминология оракула иногда просто ортогональна общепринятой.

дядя, не дойобуйся «до мишей», вчи мову і все буде ок :)

дядя, не дойобуйся «до мишей», вчи мову і все буде ок :)

Считаешь себя мышью? Окей.

В том, что это разные языки? Ну т.е. претензия сродни «почему в SQL varchar2, а в C# string — это же неудобно».

В том, что это разные языки? Ну т.е. претензия сродни «почему в SQL varchar2, а в C# string — это же неудобно».

Так в том и вопрос — а почему это «разные языки»?
ну т.е. исторически я понимаю, почему — и даже понимаю почему они не переделывают ничего
но выглядид странно
в том же т-скл — нет двух разных языков, есть одна единая платформа

Потому что by design СУБД должна была реализовывать SQL (стандарт), а дальше уже можно делать какие-то процедурные расширения на чем-нибудь ещё.
Для расширения взяли «что было» на тот момент. Если бы СУБД сейчас делали с нуля — думаю, очень многое строилось бы по-другому.

Потому что by design СУБД должна была реализовывать SQL (стандарт), а дальше уже можно делать какие-то процедурные расширения на чем-нибудь ещё.

Стандарта тогда еще не біло

я же писал — «я понимаю почему так получилось»
но єто понимание не обязано делать меня терпимім к косякам

Если понимаете, объясните, пожалуйста, и мне — я не понимаю

Если понимаете, объясните, пожалуйста, и мне — я не понимаю

Вот чуть віше Александр Липских пояснил
вкрации — «исторически сложилось, а потом уже деваться біло некуда»
Єто блин суровая правда инженерной жізни

Так а в чем проблема? Есть SQL, который реализован по стандарту, и вокруг есть язык для всякой процедурной логики — хоть язык СУБД (PL/SQL, T-SQL и прочее), хоть Java/C#/whatever для внешнего приложения.

и вокруг есть язык для всякой процедурной логики — хоть язык СУБД (PL/SQL, T-SQL и прочее), хоть Java/C#/whatever для внешнего приложения.

накладніе расході на взаимодействие — довольно таки велики
И совместимость (даже у МС) — хромает, что не может не бесить

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

Вибір між цими двома СУБД має ґрунтуватися на вимогах проєкту та складності запитів.

Архітектурне рішення має бути обґрунтоване вимогами. Не новина.
Але ви загубили один важливий якісний атрибут, особливо в сучасних умовах — досвід команди. Різниця для більшості проектів між цими СУБД мінімальна, особливо враховуючи, що дуже ймовірно, що будуть використані їх «хмарні версії».

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

Якщо підтримка транзакцій є перевагою постгреса, то це має означати, що в майскл вона або не ріалізована, або погано реалізована. А це не так, ще наче з 5 версії.
Якщо простота налаштування виділяється як перевага майскл, то в пг з цим мають бути проблеми. Знову ж не правда вже давно, а ще є клауди.
Про навантаження так само багато хайлоаду на майскл. Бізнес логіка теж не сильно обмежується вибором СУБД. Швидкість у пг теж не системно програє майскл (якщо взагалі програє)

Але ви загубили один важливий якісний атрибут, особливо в сучасних умовах — досвід команди

Тут, і так і ні, досвід важливий сперечатись не буду, але як ви самі написали

різниця для більшості проектів між цими СУБД мінімальна

тому це не дуже впливає коли не має якихось специфічних кейсів під БД.

— Щодо підтримки транзакцій, тут є нюанс, якщо використовувати mysql з двигуном зберігання myisam, то він не підтримує транзакцій. А цей двигун ще можуть використовувати в деяких специфічних сценаріях. Також в mysql блокування можуть бути більш агресивними зважаючи на план запиту через власну реалізацію MVCC.

— Щодо простоти налаштування, з postgresql все не так просто, хоча б подивитись на дефолтний autovacuum, чи розпухання таблиць при постійних апдейтах. Тому в цьому плані з mysql легше працювати.

— Про навантаження я не писав, що mysql не справляеться, але є різний хайлоад, все залежить від складності проекту, в дейяких кейсах буде postgresql краще справлятися, в деяких mysql

— Якщо реалізовувати бізнес логіку за допомогою sql запитів (а таке теж буває), то це легше робити з postgresql, тому що в неї більше можливостей

тому це не дуже впливає коли не має якихось специфічних кейсів під БД.

Якраз навпаки, якщо немає чіткого кейсу «нам потрібна спроможність Х», то вибір буде за логікою «я маю досвід з Х» або «я хочу спробувати (додати в резюме) Х».

якщо використовувати mysql з двигуном зберігання myisam

Чудовий аргумент для статті десь 2005-2010 року. По факту його не використовують (дуже рідко в околі 0). Здається (але це не точно) Перкона навіть рекомендували взагалі від нього відмовитись в контексті перформансу.

Щодо простоти налаштування, з postgresql все не так просто, хоча б подивитись на дефолтний autovacuum, чи розпухання таблиць при постійних апдейтах. Тому в цьому плані з mysql легше працювати.

Це для вас блокер? Це «економія на сірниках». Налаштування пг були проблемою років 15+ назад.

— Про навантаження я не писав, що mysql не справляеться, але є різний хайлоад, все залежить від складності проекту, в дейяких кейсах буде postgresql краще справлятися, в деяких mysql

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

Якщо реалізовувати бізнес логіку за допомогою sql запитів (а таке теж буває), то це легше робити з postgresql, тому що в неї більше можливостей

1) Погана ідея засовувати логіку в бд (особливо реляційну). Це тема для окремої статті.
2) Якщо вже вирішили, то розглядайте Оракл принаймні, а може ще й СклСервер.
2) Хранимки та трігери в майскл є десь з версії 5.

Загальна проблема:
Ви наводите аргументи, які дуже легко відкинути. З нашої розмови ми не можемо поки сформувати чітко сценарії де Технологія 1 чітко краще або гірше за 2.
Тому вибір саме реляційної СУБД буде зводитись до вимоги стейкхолдерів (дев команди чи стандарту в організації)

Якраз навпаки, якщо немає чіткого кейсу «нам потрібна спроможність Х», то вибір буде за логікою «я маю досвід з Х» або «я хочу спробувати (додати в резюме) Х».

Це якщо дають таку можливість вибору. А взагалі це холіварне питання. І я вже погодився, що досвід важливий.

Чудовий аргумент для статті десь 2005-2010 року.

Так я згоден, що він застарів, але ще є кейси, коли його використовують. Навіть досі пишуть статті по типу myisam vs innodb. Ось декілька прикладів.
medium.com/...​nd-use-cases-d9e16ebf78cc
phoenixnap.com/kb/myisam-vs-innodb
blog.devart.com/myisam-vs-innodb.html

Це для вас блокер? Це «економія на сірниках».

Якщо брати хайлоад, то це вже будуть не сірники, той хто з цим стикався зрозуміє, ось наприклад є стаття від citus про деякі кейси пов’язані з autovacuum
www.citusdata.com/...​ovacuum-problems-13-tips
Я також стикався з деякими з них свого часу.

Не залежить від складності, а залежить від наборів даних та патернів використання.

А набори даних та патерни це все частина складності проекту. Я ще не бачив складного проекту з простими патернами чи малою кількістю даних.

Якщо вже вирішили, то розглядайте Оракл принаймні, а може ще й СклСервер.

Як на мене це більш складні БД, плюс меньше людей з таким досвідом.

Срібної кулі не існує, тому я й не мав на меті дати чітку інструкцію в яких випадках, яку БД краще використовувати. Я просто навів узагальнюючі моменти в підсумках.

Тому вибір саме реляційної СУБД буде зводитись до вимоги стейкхолдерів

В тому то й проблема, що так частіше за все й буває, й мало хто вибирає БД аналізуючи згідно з вимогами проекта. Чи проводить навантаження під свої потреби. А потім не розібравшись з БД змінюють її, бо вона типу погано справляеться (як було у uber, але то тема для окремого холівару).

мало хто вибирає БД аналізуючи згідно з вимогами проекта.

Це тому що витрати часу на аналіз зазвичай не окупаються, бо ці СУБД приблизно схожі по функціоналу.

Чи проводить навантаження під свої потреби.

Оце вже ближче до конструктиву. Власне в статті «Як обрати оптимальну базу даних для вашого проєкту» я б очікував алгоритм по тиму:
— визначіться з моделями даних
— визначіться з об’ємом даних
— визначіться з патерном навантаження
— проведіть порівняльні виміри

прогноз росту даних зробити, якщо це можливо

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

Тобто у постгреса mvcc реалізований краще )? Можете розповісти чим саме? Тут недавно була стаття про те, як до хлопців завітав врапераунд через маніпуляції з автовакуум (частина реалізації mvcc в постгресі)

Я не казав, що у postgresql mvcc краще реалізований, він більше наближений до оригіналу яким його замислювали ще в 80их роках, в нього є свої нюанси, той самий автовакуум, але якщо його вмієш готувати, то проблем не буде. Тому я в статті і вказував, що mysql легший в адмініструванні.

я перепрошую а шо «підтримка транзакцій» у сучасній скбд — це якась опція про яку треба у релізах писати???

Одним словом краще взяти Оракл🤣

Багато букв

Написав би оце а не реферат

Якщо підсумувати:

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

У корпорацій зараз хайп на «не платити за ліцензію»
І амазон Аврора гарно цю нішу заповнює.

А так на локальних серверах дорожче платних версій
Оце і все

Засрали ефективні менеджери нішу

Все одно mysql i postgresql залишаются самими популярними БД. А в статтi я намагався показати рiзномаїття можливостей якi вони надають, щоб люди могли згадати, а може i дiзнатися щось нове для себе. Тому стисло тут не вийде.

І кожен пише оце

PostgreSQL почав свою історію в 1986 році як проєкт POSTGRES

Ніби ти там стояв чи за пивом бігав

Кожному своє, але наприклад я полюбляю iсторiю, тому менi цiкаво було почитати як створювалися БД, ну i там по мiнiмуму написано, якщо тобi нецiкаво пропускай цей роздiл

В сегменті малих програм і кастрмерів і тепер ще може мікросервіси додали життя

Професійні розробники з більшою ймовірністю будуть використовувати PostgreSQL, тоді як новачки — навпаки MySQL.

Огляд непоганий, але я б сказав що це суб’єктивна оцінка

Це не суб’єктивна оцінка, це просте порiвняння хто що вибирає, взяте з опитування stackoverflow. Продублюю сюди посилання survey.stackoverflow.co/...​24/technology#1-databases
там ви побачите, що professional developers 51% вибирают postgresql, а 39% mysql. А lerning to code — 44% mysql i 33% postgresql.

ON DUPLICATE KEY DO NOTHING

В MySql це Id = Id

Це все одно не аналог, тому що при такому пiдходi буде оновлення (хоча id i не змiниться), але буде зроблено запис в журналi транзакцiй, що може вплинути на продуктивнiсть.
Краще вже тодi використовувати INSERT IGNORE.

Що на рахунок профілей навантаження? В яких умовах, яка з баз себе краще показує?

Залий на прод і відійди)
Можна подумати у всіх однакові юз кейси

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

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

З мого досвіду воно спочатку починає упиратися або в не оптимальні запроси (або схему даних), або в налаштування ОС — як то диску чи мережевого стеку, і вже потім в особливості СУБД. ;)

PostgreSQL підтримує стандартний SQL-підхід до обробки NULL. Для порівняння значень NULL використовується IS NULL або IS NOT NULL. У MySQL нестандартна поведінка під час використання оператора = із NULL. Наприклад, NULL = NULL повертає NULL, а не TRUE, що може призвести до неочікуваних результатів при некоректній обробці значень NULL. Тому при роботі з NULL завжди потрібно використовувати IS NULL або IS NOT NULL для коректного порівняння.

як на мене то тут не завадило би якось переформулювати. Бо якщо не вчитуватися, то виглядає як «у постре є стандартний із нулл, а мускл погано порівнює, тому необхідно використовувати із нулл».

Згоден, тут трохи накрутив з роз’ясненням. Малося на увазi, що для порiвняння краще використовувати IS NULL/IS NOT NULL в обох БД.
А про нестандартну поведінку mysql, малося на увазi, що можна змiнювати її за допомогою параметра sql_mode. А postgresql суворо дотримується стандарту SQL без додаткових режимів.

поставте Оракл та не мучайтесь

якщо не на макбук, то комент не защітується.

Спочатку питали «чому не з окопа пишеш?», а тепер «чому не з макбука?»

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

постав оракл KDE2 на макбук під лінуксом FreeBSD і пропатч

А вже була стаття як поставити на макбук оракл через хомбрю?

Нащо стояти у заторах. Купи гелікоптер і не парся

Oracle це про великi ентерпрайзи. Вона дорога, складнiша в адмiнiструваннi, потребує бiльше ресурсiв i також має безлiч нюансiв. Тому дякую, але нi :)

яки там ресурси... я на 128 мб колись запускав

Це все залежить вiд ситуацiї, можливо для того вашого кейсу для mysql i postgresql вистачило б 64мб :)
Але те що я бачив/читав, то Oracle на великих данних потребує значних ресурсiв.

Так будь яка база потребує усю пам’ять під кеш блоків даних, чим більше тим краще!

еликi ентерпрайзи

Великі страшні ентерпрайзи :-)
У нас якось у ентерпрайзі були Oracle і MS SQL і сиділи в одному кутку кабінету адміни Oracle та адміни сіквела. Так от ораклоїди ходили завжди якісь похмурі та за***ані, на столах був безлад, не з ким не контактували не по робочім питанням. Адміни MS SQL веселі, доброзичливі, постійно замовляли піцу, на столах був порядок.
Ми їх так і називали — темна сторона і світла сторона БД :-)

А ще був менеджер який дуплч не відбивав але хотів схрестити їх в один вид
Ти ж програміст ой дба

Підтримка опенсoрсу (не зовсім про оракл)
Дорожча якщо це не managed service
І ризики вище

Тобто економиш одним днем
А потім вигрібаєш проблеми

А покрашувачі нагівеокодили і далі пішли

то у вас були неправильні ораклісти !
а ораклоід — «подібний до оракла», тобто людину так називати некоректно :)
та скажу по секрету — у базі коли усе налагодив можна майже нічого не робити днями, тому я завжди ще програмувсав на ораклі щоб не отупіти
а усі проблеми були від криворуких програмерів — індусів в ораклі або наших «рукосраків» яки проектують бази не маючи уявлення про 3 нормальні форми та пишуть код без врахування масштабування системи...

Пане добрий, якi там нормальнi форми? Не вчiть поганому. Вже давно розроблена унiвнрсальна структура: база данних — це купа таблиць виду (Table_ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY, Table_XML XML NULL, Table_JSON JSON NULL). Потiм до такоi краси прикручуються мiкросервiси, бекенд i т.п. Врештi-решт цей монстр урочисто виiздить в якусь хмару. Коли все починае ставати колом, погромiст робить круглi здивованi очi i каже «Але ж можна купити платиновий/дiамантовий/рубiновий доступ. Ресурсiв вистачить — ядерний вибух он-лайн обчислити» , аот грошей — нi

ну я все ж надіюсь якщо людині дали проектовати базу то вона хоч про 3 форми прочитала...

я сам можу книжку написати «як робити не треба» :) за 27 років роботи з ораклом

а самий сок коли в тебе держреєстри, хмара не працює (раджеш провтикав ... буває) а мають тебе як CTO

тому я одразу cказав шефу — хочете бігати до міністра з вазеліном — арендуйте безплатну скбд у хмарі :)

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

Вы думаете, SQL Server-у бы не поплохело от битого кластера? Если сыпется диск, то это уж явно не проблема Оракл

це проблема дба який не створив дзеркало на рейді для бд та нічого не розуміє в рекавері

прочтіть книжку по oracle backup and recovery

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

за «чтение» не платять платять за роботу

в мене оракл бігав ще в тому сторіччі.
Ну і безкоштовна версія покриває багато потреб.

Безкоштовна ніби то була до 4Гб бази? На таких обʼємах, вибачте, і sqlite працюватиме норм ;)

так, там помилка ОRА- під це написана навіть
якось чоловік телефонував просив щось зробити з базою така була у нього проблема
кажу ставте ентерпрайз та не партесь :)

було десь 300+ гб. повний бекап займав десь 5-6 годин на корзині із scsi (бо сата ще не придумали тоді в нас)

Ну зараз (та й 10 рочків тому) такий обʼєм легко потягне будь-яка з трьох...

в ті часи головне було не що за база, бо можливо і mysql і postres вже могли б потягнути.
А ось диски тоді були 600$ за 36 гб.

оракл був, бо там було комплексне рішення на базі оракл та оракл applications, і це був дуже крутий скачок до оракла з фокспро

Ну з фокспро так, не до ночі буде згадана ;)

там rman дает кучу вариантов бэкапа, холодный самый долгий, а в горячем режиме rman забирает инкрементальные логи и накатывает их на бэкап. Гигантские базы на проде никто не останавливает то что это ппц

рман нічого не накатує, накатує інстанс

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

кожному своє ©
я штудировав маючи зп 300 долл
але це дало свої плоди

до речі по рману там небагато читати, яки там ще тома?

це був, наскільки я пам’ятаю 7 версія, чи може навіть шоста.
В нас були інкрементальні з 20хвилинним скидом транзакшен логів на окремий NAS, та повний бекап кожні вихідні, щоб інкрементальні простіше було накатувати.
На той момент в нас було всього два сервера такого розміру, щоб більш-меньш воно нормально встигало, це був 99 рік, тільки-тільки вийшов пентіум-3, так як до sata та ssd ще нескоро, то була корзина scsi дисків в 10му рейді з батарейками.

На вихідних була ніч з суботи на неділю, щоб можно було зробити бекапи. Взагалі спочатку було десь 12 годин, але придумав схему щоб воно компресіровали на сервері, але результат скидало одразу по 100мбіт на NAS, вийшло майже вдвічі скоріше.

ні, фармацевтична компанія (тоді була найбільшою в країні).

фармак?
тоді у 90-ті оракл буд в мвс, уз, пфу, податковій та сбу — це я точно знав

фармак від нас по капіталізації відставав разів у 3-5 =)

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

ви понакидували не маючи уяви про шо пишете
це тролінг?

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

я не став ламати через Anydesk та orapwd бо хз може там пароль SYS у програмі прописаний :) тож зовсім працювати не буде

це тролінг?

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

Підписатись на коментарі