The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года

04.01.2024 12:04

Издание DB-Engines обновило свой рейтинг популярности СУБД и присудило звание СУБД 2023 года проекту PostgreSQL, который за год продемонстрировал наибольших рост популярности из 417 отслеживаемых систем. Второе место присуждено облачной платформе Databricks, которая за год поднялась с 19 на 17 место в рейтиге, а третье место занял движок Google BigQuery, который поднялся с 21 на 19 место в рейтинге.

Ранее PostgreSQL уже признавался СУБД года в 2020, 2018 и 2017 годах. В 2022 и 2021 годах это звание было закреплено за СУБД Snowflake, в 2019 - MySQL, в 2016 - Microsoft SQL Server, 2015 - Oracle, 2013 и 2014 - MongoDB.

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

Что касается распределения СУБД в рейтинге, PostgreSQL продолжает занимать 4 место, несмотря на наибольший во всем рейтинге рост популярности - 34.11 балла. Рост популярности также демонстрирует проект Databricks (+19.7 баллов, подъём с 19 на 17 место), Google BigQuery (+9 баллов, с 21 на 19 место) и Snowflake (+8.66 баллов, с 11 на 9 место). C 8 на 7 место поднялось хранилище Elasticsearch, с 33 на 29 - СУБД Firebird, c 44 на 37 - ClickHouse, с 62 на 50 - Prometheus, с 48 на 42 - OpenSearch, с 85 на 76 - TimescaleDB.

Значительное снижение популярности за год наблюдается у MySQL (-88.5 баллов), Microsoft SQL Server (-42.79), MongoDB (-37.70), Redis (-18.17) и SQLite (-16.29). С 7 на 8 место опустилась СУБД IBM Db2, c 10 на 11 - SQLite, с 43 на 45 - CouchDB, с 57 на 60 - CockroachDB.





  1. Главная ссылка к новости (https://db-engines.com/en/blog...)
  2. OpenNews: Рейтинги популярности языков программирования и СУБД в 2019 году
  3. OpenNews: Анализ популярности языков программирования и СУБД в 2017 году
  4. OpenNews: Рейтинг популярности СУБД за 2015 год
  5. OpenNews: Опубликована 62 редакция рейтинга самых высокопроизводительных суперкомпьютеров
  6. OpenNews: Релиз СУБД PostgreSQL 16
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60388-postgresql
Ключевые слова: postgresql, db-engines
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (201) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.5, Аноним (5), 12:24, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то SQLite3 и Metakit4 не любят...
     
     
  • 2.7, Аноним (7), 12:26, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –13 +/
    Психически здоровые люди в принципе не должны пользоваться SQLite3 ни в каком виде.
     
     
  • 3.8, Аноним (5), 12:28, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Айфоном пользуешься?
     
     
  • 4.17, Аноним (7), 12:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пользователь скулайта детектед.
     
     
  • 5.22, YetAnotherOnanym (ok), 13:38, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Боишься пользователей скулайта?
     
     
  • 6.26, Аноним (26), 14:08, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Этак можно каждый раз пугаться, проходя мимо зеркала.
     
     
  • 7.27, Аноним (26), 14:09, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сильно лучше, чем "в простых текстовых файлах", как завещали основатели UNIX.
     
     
  • 8.50, Аноним (26), 16:51, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На самом деле, этот комментарий должен был быть в соседней ветке Акела прома... текст свёрнут, показать
     
  • 3.15, Аноним (15), 12:49, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    SQLite используется браузерами для хранения всех данных. Достаточно здорово?
     
     
  • 4.16, Аноним (7), 12:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучши показатель худшего при применения.
     
     
  • 5.29, Аноним (29), 14:12, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Предлагаешь рядом с каждым браузером MySQL поднимать?
     
     
  • 6.31, Аноним (31), 14:32, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Помню толи в KDE3, только в KDE4 был какой-то музыкальный проигрыватель с хранением данных в MySQL. Пля какая тормознутая жесть это была.
     
     
  • 7.35, Аноним (5), 15:07, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да там и сейчас KOrganizer MariaDB использует.
     
     
  • 8.41, Аноним (41), 15:42, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Надо для программы ведения заметок прикрутить Оракл с партициями, кучей индексов... текст свёрнут, показать
     
  • 8.120, Аноним (120), 10:11, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ох да Как-то органайзер искал, решил на этом остановиться, пока на процессы н... текст свёрнут, показать
     
  • 7.77, Аноним (77), 20:55, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://www.mysql.com/customers/
     
  • 7.130, Аноним (130), 12:11, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, это Amarok. Серверную СУБД использует для хранения музыкальной коллекции.
     
  • 5.131, Аноним (131), 12:27, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прикол в том, что такие, как ты, никогда не смогут сделать всё то что в прикладном софте делается через SQLite дёшево и сердито, не говоря уже о "лучшем применении", простоте работы с этим, надёжности, производительности, размерах, портабельности...
     
     
  • 6.180, Аноним (180), 21:14, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нет никакой проблемы навернуть какую-нибудь log-structured хрень на коленке на текстовых файлах в читабельном для человека виде, с транзакциями, контрольными суммами и компакшенами. От SQLite здесь требуется только хранение данных между перезапусками приложения, сами базы мелкие и все данные из них можно грузить сразу в память. Собственно потому log базы для этого отлично подходят и они просты в реализации.
     
  • 4.43, Аноним (43), 16:19, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Используется любыми программами, которым не похер на сохранность данных. Браузерам, кстати, похер -- они повреждаются и обнуляются только так, несмотря на скулайт.
     
     
  • 5.98, Аноним (7), 00:19, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Похер как раз скулайту. Потому что он не подходит для данной задачи.
     
     
  • 6.99, Аноним (43), 00:25, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Идеально подходит и обеспечивает абсолютную надёжность и защиту от потери бесценных данных.
     
  • 5.146, нах. (?), 15:06, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не хотел бы тебя огорчать, но обнуляется и повреждается твоя любимая мразила именно потому что вместо sqlite по каким-то них-причинам ее рабы перешли на самодельные xml и нескучные json.

    (Вот например эта - с которой пишу - не может запомнить размеры окон при перезапуске. Причина хорошо известна, как лечить - никто не знает. Пока эта инфа хранилась в sqlite - все просто работало.)

     
  • 3.119, anonymous (??), 10:02, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше бы, конечно, gdbm.
     
     
  • 4.151, Аноним (151), 16:44, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.gnu.org/software/gdbm/ редиректит (302) на https://www.gnu.org.ua/software/gdbm/ , а в РФ блокируют сайты в ua-доменах все подряд, включая gnu.org.ua. Не раз сталкивался с тем, что нужно скачать дейташит, а он зачастую на ua-сайте, ни одного политического сообщения на странице нет - а сайт всё равно заблочен просто за то, что в ua-домене.
     
  • 4.152, Аноним (151), 16:49, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.gnu.org/software/gdbm/manual/Copying.html
    >This library is free
    >GNU dbm (GDBM) is not in the public domain; it is copyrighted and there are restrictions on its distribution

    /0

    >GDBM is currently distributed under the terms of the GNU General Public License, Version 3.

    ффтопку.

     
     
  • 5.171, lockywolf (ok), 19:39, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Специально для тебя есть berkeley db.

     
  • 5.172, Аноним (43), 19:44, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не ной, это одна из реализаций. И никто не запрещает тебе отправлять в неё данные через system. Если прям так хочется воровать чужой код, возьми какую-нибудь cdb, она лицензирована как общественное достояние. Кстати, gdbm надёжнее той же leveldb. Я до сих пор не столкнулся с рандомными уничтожениями файлов (от всего) в ней, что для leveldb обычное дело.
     
  • 2.23, rshadow (ok), 14:00, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого надо по рынкам смотреть, ведь они тоже неравномерно друг относительно друга растут. И тогда уже смотреть на лидеров конкретного направления.
     
  • 2.25, Аноним (26), 14:07, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Что-то SQLite3

    Потому что рейтинг в основном учитывает вопросы и обсуждения. Так как функциональность у SQLite крайне мала по сравнению с серверными СУБД, то и обсуждать там особо нечего.

     
     
  • 3.36, Аноним (5), 15:10, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно. Поэтому многопользовательность и прочие сложности обеспечения консистентности тут не нужны. В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение. Кому надо покомпактнее без сложных SQL-запросов - тому наверное лучше метакит или вообще LMDB.
     
     
  • 4.37, Аноним (37), 15:17, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Ну так SQLite-базу обычно одно локальное приложение и пишет одновременно.

    Это не так...

     
     
  • 5.48, Аноним (26), 16:48, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну попробуйте из двух приложений одновременно писать в одну базу данных SQLite.
     
     
  • 6.51, Аноним (5), 16:52, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну вообще можно и делается, но если такой use case не является целевым, то лучше заблокировать базу эксклюзивно, и производительность операций с ней вырастет.
     
     
  • 7.60, Аноним (37), 18:51, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    да. имеено поэтому sqlite значительно превосходит в скорости записи и чтения все серверные субд, но не во всех случаях может бытьиспользован
     
     
  • 8.63, Аноним (26), 19:01, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пользователи Redis с вами не согласятся ... текст свёрнут, показать
     
     
  • 9.132, Аноним (131), 12:30, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Бенчмарки в студию Но только чтобы эти данные вот прям сохранялись, а не мы ту... текст свёрнут, показать
     
     
  • 10.149, Аноним (37), 16:01, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    более того я уверен что sqlite в режиме inmemory уделает redis очень просто ... текст свёрнут, показать
     
  • 6.111, Антонимусс (?), 07:37, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    'PRAGMA journal_mode = wal2;' и пишите сколько нужно.
     
  • 4.61, Аноним (180), 18:55, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  В SQLite больше всего бесит отсутствие схемы, что приводит к оверхэду на хранение.

    Ещё один размороженный. Добро пожаловать в 2024-ый, уже 20 лет прошло с твоей заморозки, мир сильно изменился

    https://www.sqlite.org/version3.html
    https://www.sqlite.org/fileformat.html

     
     
  • 5.73, Аноним (5), 20:03, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для тех кто в танке каждое значение имеет заголовок с типом, при этом даже если... большой текст свёрнут, показать
     
     
  • 6.75, Аноним (75), 20:30, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну так выпусти!
    Тут тебе никто ничего не должен...
    Я дажe название подскажу: "SQLiteLE"
     
  • 6.133, Аноним (131), 12:31, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит как боль чувачка, который не смог в ORM и нормальные миграции
     
     
  • 7.153, Аноним (153), 17:02, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ORM - это говно, которое имеет смысл использовать только поверх key-value хранилища. Потому что смысл ORM - это просто прозрачное для прогркммиста получение данных по ключу и сохранение данных по ключу, а все операции делаются на стороне приложения. Для этого движок SQLite с индексами, оптимизацией сложных запросов и оверхедом на всё это просто избыточен: сам ORM строить подобные запросы не умеет. SQL используют там, где надо не просто хранить бизнес-данные, но ещё эффективно их выбирать, пересылая только те, что нужны, и модифифировать, избегая ненужных запросов. Поэтому у меня используется ванильный SQLite + ООП-обвязка + мои кастомные запросы, оптимизированные вместе со схемой. Но не ORM.
     
     
  • 8.174, Аноним (43), 19:55, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не стоит демонизировать орм, это отличная штука на практике Большинство практич... текст свёрнут, показать
     
  • 8.176, Аноним (43), 19:59, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    я не знаю, что у тебя за орм, но нормальный орм всё это умеет, и, кроме того, по... текст свёрнут, показать
     
  • 8.179, Аноним (180), 21:07, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ORM есть смысл использовать только когда совсем не умеешь работать с базами данн... текст свёрнут, показать
     
  • 6.178, Аноним (180), 21:02, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ок, проблема понятна. Да, неприятная особенность SQLite. Только это не проблема эффективности хранения и отсутствия схемы, а проблема отсутствия ограничений по типу. Хранение тут более-менее эффетивное, но не самое оптимальное. LE или BE для СУБД вообще никакого значения не имеет, считай это особенностью кодирования. СУБД может хранить числа как угодно, хоть всё в VARINT-ах или поколоночном delta кодировании на битах. LE или BE имеет значение толлко когда есть возможность работать с данными прямо из хранилища, SQL СУБД такой фичей не обладают.
     
  • 2.104, пох. (?), 00:50, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вопросы про sqlite просто не попадают в статистику, кроме совсем уж нубов.

    И те если не после первого попадания то раза с десятого хотя бы уже обычно дальше sqlite.org с ними и не ходят.

    А "у меня кончилось место на постгрезовом диске, штаделаааатьпамагиитя" - каждый день по сто тыщ.

     
     
  • 3.134, Аноним (131), 12:33, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Всё ещё лучше чем "мы использовали на проде MS SQL CE и БД перевалила за 4Гб, как жить дальше?".
    Про окакл вообще пугающе дофига вопросов (или правильнее читать проблем?)
     
     
  • 4.145, нах. (?), 15:02, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    э... я боюсь даже вводить такой запрос.

    (ms sql ce - на минуточку, в девичестве "ms sql for windows CE". Для запуска на пда о 64 мегабайтах оперативы.)

    > Про окакл вообще пугающе дофига вопросов (или правильнее читать проблем?)

    дык - "чтоб денег никому не платить".
    Особенно в свете проблем одной интересной страны без международно признанных границ.

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

    Если его вместо mysql использовать - то вряд ли ты осчастливишь статистику такими запросами - он просто будет работать, даже неинтересно.

     

     ....большая нить свёрнута, показать (50)

  • 1.6, Аноним (7), 12:25, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    Уж не потому ли что в одной стране постгрей замещают весь тухлый орацле?
     
     
  • 2.9, Аноним (5), 12:33, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в чём смысл именно базы Oracle (помню, что у оракла есть какая-то очень крутая энтерпрайзная технология на основе очереди событий, огромной библиотеки обработчиков и с возможностью добавлять собственные блоки, но это, наверное, другая история)?
     
     
  • 3.12, Аноним (5), 12:36, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А, вспомнил, Oracle BPM называется.
     
  • 3.18, Аноним (77), 12:59, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >в чём смысл именно базы Oracle

    https://www.oracle.com/support/

     
     
  • 4.30, Аноним (30), 14:23, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так забацали же Postgres Pro, добавили в реестр.
    И ты сможешь получить такой же саппорт там. Ну, почти такой же!
    Так что даже выиграли!
     
     
  • 5.32, Аноним (26), 14:54, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Учитывая последние крупные сокращения в Oracle — как минимум, не проиграли.
     
     
  • 6.38, Аноним (77), 15:19, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Эх, знал бы Ларри, как за него тут переживают, прослезился бы... наверное :)
    https://www.datacenterdynamics.com/en/news/oracles-larry-ellison-were-building
     
  • 3.64, Аноним (180), 19:13, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, что undo segments в Oracle DBMS более правильное техническое решение, чем аналог в PG. В Oracle больше отладочных данных для поиска затыков, больше статей по оптимизациям. С другой стороны, в PG больше типов данных, но для счёта денюжек это не фича. В принципе можно жить хорошо и с PG если развивать ИС с нуля на PG. Но миграция может оказаться очень болезненной и проблемной.
     
  • 3.105, пох. (?), 00:55, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А в чём смысл именно базы Oracle

    в том что она как правило - работает.
    А когда все же приходит с ora006 - можно обратиться в техподдержку и тебе индус популярно объяснит что сравнивать содержимое xml-атрибута вообще говоря можно, но для этого атрибут хотя бы в этом xml должен быть ;-)

    А если тебе нужна просто реляционная субд - то обычно и mysql достаточно (ну или вовсе sqlite)

    И никаких тебе вакуумов которые ну уже совсем окончательно победили и объявили deprecated, но опять что-то помешало.

     
     
  • 4.156, Аноним (26), 17:59, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А если тебе нужна просто реляционная субд - то обычно и mysql достаточно (ну или вовсе sqlite)

    Видимо, ни с чем сложнее KDEшных приложений вы дела не имели.

     
  • 4.165, Аноним (165), 18:55, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ничего не понял.

    >в том что она как правило - работает

    SQLite работает. Postgres работает. MariaDB/InnoDB работает. LMDB работает. MongoDB работает. Neo4J работает. Любая успешная база работает. Не вижу в этом аспекте никаких отличий.

    >можно обратиться в техподдержку и тебе индус популярно объяснит что сравнивать содержимое xml-атрибута вообще говоря можно, но для этого атрибут хотя бы в этом xml должен быть ;-)

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

     
     
  • 5.181, Аноним (181), 21:30, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >SQLite работает. Postgres работает. MariaDB/InnoDB работает. LMDB работает. MongoDB работает

    До первого хорошего кабздеца на критичных и очень дорогих карману данных. И тут-то высняется, что будь там оракел, отделались бы испугом, а тут или вообще все в хлам, или многодневное восстановление, а это лямы убытков. Оракелу-то аналогов и нет, по большому счету.

     
     
  • 6.182, Аноним (26), 22:26, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну да, точно, оракел же сам Кашпировский зарядил на неломаемость, так что он сохранит ваши данные, даже если датацентр выгорит полностью.
     
     
  • 7.185, Аноним (180), 22:44, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В серверных СУБД есть репликация и это относительно стандартные сетапы. В SQLite нет ничего кроме защиты от краха ПО во время записи в файл бд
     
  • 7.188, Аноним (181), 00:43, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Иди хотя бы доки по оракелу почитай, а потом по постгрям всяким, и призадумайся, что такого во оракеле есть, чего нет в постгрях, и зачем вообще это нужно.
     
     
  • 8.190, Аноним (26), 02:08, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и знал, что ничего, кроме бла-бла-бла , от вас, маркетологов, не добиться ... текст свёрнут, показать
     
     
  • 9.193, Прохожий (??), 12:29, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У Oracle есть такая технология, как Flasback Database Для огромных баз данных -... текст свёрнут, показать
     
     
  • 10.211, specter (ok), 18:17, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это которая PITR в PG Это которые https www postgresql org docs 11 different-... текст свёрнут, показать
     
     
  • 11.214, Прохожий (??), 00:25, 11/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это гораздо, на порядки, быстрее, чем PITR Почему Потому что у тебя нет необхо... большой текст свёрнут, показать
     
  • 5.210, Аноним (210), 17:25, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пока есть такие "специалисты", у нас будет работа.
     
     
  • 6.219, пох. (?), 09:54, 16/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока есть такие "специалисты", у нас будет работа.

    мляя, а НОРМАЛЬНОЙ работы - что, уже совсем нет?!

    Вот всю жизнь мечтал выносить горшки за альтернативно-одаренными (прямо в офисе куда их по квотам набирают)


     
  • 2.14, Аноним (77), 12:48, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >замещают весь

    https://www.kommersant.ru/doc/6199827

     
     
  • 3.28, Аноним (26), 14:11, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Любая миграция стоит денег, а банкиры отлично умеют считать деньги.
    Естественно, выгоднее будет ничего не мигрировать, а просто поныть и попросить подачек.
     
     
  • 4.123, Аноним (123), 11:06, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не все банкиры одинаково сообразительны.
     
  • 4.194, Прохожий (??), 12:33, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Проблема не только в миграции, как таковой. Проблема ещё в технологической ущербности (по сравнению с Ораклом) других СУБД такого же класса.
     
  • 2.122, Аноним (123), 11:05, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Орокле в лицензии прописали что им обязаны предоставить доступ на любой объект, включая военный и закрытый город и конечно же они посланы.
    Там даже запрещать бесполезно ввиду неприемлемой лицензии.
     
     
  • 3.135, Аноним (7), 12:37, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Протри глаза это Оракл ушел. Ораклом пользовался или даже пользуется даже Центробанк.
     
     
  • 4.166, Аноним (166), 18:58, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ещё раз, нахрена именно оркал? SQL везде примерно одинаков. За что именно платят оркам сотни нефти за лицензии на базы? Что там такого в этой DBMS, что нет ни у кого другого?
     
     
  • 5.169, пох. (?), 19:30, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ещё раз, нахрена именно оркал? SQL везде примерно одинаков.

    эксперт опеннета пожаловал.

    > За что именно платят оркам сотни нефти за лицензии на базы? Что там такого

    вот когда ты это наконец узнаешь - тогда и приходи.

    Ну или хотя бы с "примерно одинаковым SQL" разберешься.

     
  • 5.183, Аноним (26), 22:28, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ещё раз, нахрена именно оркал? SQL везде примерно одинаков. За что именно платят оркам сотни нефти за лицензии на базы? Что там такого в этой DBMS, что нет ни у кого другого?

    Самые крупные суммы контрактов — соответственно, самые крупные откаты. Оно и в этой стране, и в Европе, и за океаном высоко котируется.

     
  • 5.195, Прохожий (??), 12:37, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё раз. С Ораклом тебе гораздо проще рулить базами с ценными данными. Просто иной раз на порядок проще. Потому что разработчики Оракла изначально были нацелены на Энтерпрайз решения, а не на сайтик Васяна из Мухосpанска.
     

  • 1.10, iPony129412 (?), 12:34, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    До 2022 работал только с Oracle, но потом что-то случилось, и теперь PostgreSQL
     
     
  • 2.45, Аноним (26), 16:42, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На самом деле, процесс шёл с 2014 года, просто с 2022 он ускорился.
     

  • 1.13, Карлос Сношайтилис (ok), 12:36, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Странно ставить в один ряд и сравнивать PostgreSQL и Databricks – on-premise приложение и облачную платформу.

     
     
  • 2.39, Аноним (37), 15:23, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    вообще странный рейтинг да
    там например есть и Postgres и PostGIS
     

  • 1.19, Аноним (19), 13:20, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    То, чего не должно быть, на 3-м месте.
     
     
  • 2.33, Аноним (26), 14:55, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Такая же проприетарь, как и оракл.
     
  • 2.66, Аноним (180), 19:15, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    То, чего не должно быть, на 2-ом месте - php в мире СУДБ
     
     
  • 3.79, Аноним (26), 21:04, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее, аналог JavaScript.
     
  • 3.86, Tron is Whistling (?), 22:24, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Причём с феерическим отрывом от хламвари, которая на 4.
     

  • 1.20, лютый жабби.... (?), 13:24, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всю отбитость этого "рейтинга" демонстрирует его содержимое. Эластиксёрч у вас на 7м месте, а нео4ж на 20м.... ну всё, теперь буду графы эластиком считать (буг0г0г0)
     
     
  • 2.52, Аноним (5), 16:53, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Use caseы разные.
     
  • 2.62, Аноним (26), 18:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > теперь буду графы эластиком считать

    А я даже знаю контору, которая каждое ребро графа сохраняет как документ в эластике (причем версии 2.4).

     
  • 2.91, fuggy (ok), 23:34, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там в полной версии таблички Database Model написана. Так что никого ты не переиграл.
     

  • 1.34, Аноним (34), 15:02, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ура, Firebird рванул вверх!
     
     
  • 2.40, Аноним (37), 15:24, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    чему Вы радуетесь ?
     
     
  • 3.46, Аноним (26), 16:43, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Что открылся путь из царства теней в мир живых?
     
  • 3.85, Аноним (34), 21:35, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что Firebird рванул вверх, неужели не ясно? Ну ты и тупица!
     
     
  • 4.89, Аноним (26), 22:52, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А что в этом радостного, если не секрет?
     
     
  • 5.196, Прохожий (??), 12:41, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто других СУБД он в жизни не видел, только эту смог освоить.
     

  • 1.42, Аноньимъ (ok), 15:51, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    > PostgreSQL

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

     
     
  • 2.44, Карлос Сношайтилис (ok), 16:37, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > По какой-то причине очень любима ентерпрайз галерами.

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

     
     
  • 3.49, Аноним (26), 16:49, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так и мускуль бесплатен, но почему-то используется в основном для друпала и вордпресса.
     
     
  • 4.68, Аноним (180), 19:21, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Потому что MySQL криво спроектирован, от реализации SQL и до методов настройки хранилищ. PG это коробочное решение с корректным SQL и с ровно одним рабочим бэкэндом со всеми фичами и плюсами такого подхода. Также PG по фичам и SQLю ближе к другим коммерческим СУБД.
     
     
  • 5.80, Аноним (26), 21:09, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я помню, у мускуля тоже остался ровно один рабочий бэкенд (не считая одного проприетарного).
     
  • 5.87, Tron is Whistling (?), 22:26, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    PG - это очередная глорификация DBF, поэтому он идёт нафиг.
     
     
  • 6.88, Аноним (26), 22:50, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С таким потрясающим знанием матчасти лесом идёте вы.
    Увы и ах.
     
     
  • 7.117, Tron is Whistling (?), 09:44, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну так чё там, страничную организацию и переиспользование страниц уже добавили, или всё ещё построчник и вакуумы? :D
     
     
  • 8.139, Аноним (139), 13:28, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https www opennet ru opennews art shtml num 59453 ... текст свёрнут, показать
     
     
  • 9.141, Tron is Whistling (?), 14:24, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Целый навесной бета-костыль, надо же Ну, может, такими темпами лет через 20 и с... текст свёрнут, показать
     
  • 9.143, нах. (?), 14:54, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    дык, эта статус паблик-беты не меняется уже пол-года Когда там еще эти пчьол... текст свёрнут, показать
     
     
  • 10.175, Аноним (180), 19:56, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не уже, а всего лишь Типичное время вендрения чего-либо это 1-5 лет если апстри... текст свёрнут, показать
     
     
  • 11.209, нах. (?), 16:40, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    так это наверное нескоро с ну в смысле можно считать что скорее нет чем ест... текст свёрнут, показать
     
  • 8.158, Аноним (26), 18:08, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как и было отмечено выше, знание матчасти у вас действительно около нулевое есл... текст свёрнут, показать
     
     
  • 9.191, Tron is Whistling (?), 10:29, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну и как там с переиспользованием ... текст свёрнут, показать
     
  • 8.167, Аноним (180), 19:24, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Почти все реляционные СУБД работают со страницами, а внутри, внезапно, строки В... текст свёрнут, показать
     
     
  • 9.192, Tron is Whistling (?), 10:35, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А ведь да, я таки посмотрел в его on-disk format И страницы есть, и даже free s... текст свёрнут, показать
     
  • 7.118, Tron is Whistling (?), 09:49, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Схему на ходу менять можно, или надо все эннадцать терабайт имеющихся данных перелопачивать?
     
  • 5.113, Антонимусс (?), 08:43, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    MySQL спроектирован просто офигенно, а инженеры из Oracle потом залечили детские болячки - эти ребята разбираются в базах и хорошо знают свое дело.
     
     
  • 6.157, Аноним (26), 18:01, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так "офигенно спроектирован" (уже смешно, кстати) или всё-таки имел "детские болячки"?

    "Во-первых, я кувшин не брала, во-вторых, уже вернула, в-третьих, он уже был с трещиной"

     
  • 2.47, Аноним (26), 16:47, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Подозреваю по причине сложности настройки и эксплутации, можно посадить клиента на поддержку по самые нехочу.

    Нет, по причине отсутствия опенсорсных конкурентов.
    Мускуль — менее универсален, у него узкая ниша лендингов и мелких интернет-магазинов с десятком посетителей в день. За рамками этой ниши начинаются такие сложности, что дешевле на постгрес переехать.

     
     
  • 3.53, Аноним (53), 17:43, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и смысл тогда мумкуль брать? Для пары посетителей хватит и дефолтной настройки постгри
     
     
  • 4.55, Аноним (26), 18:02, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так и смысл тогда мумкуль брать?

    Потому что PHP-разработчики, которые за $2/час подпилят друпал под нужды малого бизнеса, обычно умеют подключаться только к мускулю.

    > Для пары посетителей хватит и дефолтной настройки постгри

    Не все это знают. Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.

     
  • 3.58, Аноньимъ (ok), 18:17, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какие сложности начинаются с мусклом?

    Я недавно на нем небольшую базу для аналитики гонял, что-то ок 60Гб. Оно вообще ну очень быстро работает. Что там такое должно быть чтобы мускл затык, а постгря справилась?

    Кстати видел эту постгрю в энтерпрайзных галерах. Они умудряются её реально тормозить на десятках и сотнях запросов, потому что DB Инженер - это видимо уже немодно и ненужно.

     
     
  • 4.59, Аноним (26), 18:21, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати, это вы тот PHP-разработчик, который допиливает друпал на $2/час?
     
     
  • 5.67, Аноньимъ (ok), 19:17, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.

    Я PHP в его лучшие годы не трогал. Концепцию смеси серверного кода с html разметкой считаю ужасной, и не безопасной.

     
  • 5.69, Вы забыли заполнить поле Name (?), 19:24, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если работать 24 часа в день, то нормально :D
     
  • 4.82, Аноним (26), 21:16, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Я недавно на нем небольшую базу для аналитики гонял, что-то ок 60Гб. Оно вообще ну очень быстро работает. Что там такое должно быть чтобы мускл затык, а постгря справилась?

    Использовать OLTP для аналитики — уже многое о вас говорит.

    Наверное, "ну очень быстро" — это когда запрос отрабатывает за выходные?

     
     
  • 5.124, Аноньимъ (ok), 11:30, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Использовать OLTP для аналитики — уже многое о вас говорит.

    Если оно работает, и каши не просит - то всё отлично просто.
    Перестанет хватать - разверну что-то более серьездное. Но не постгрю.

    > Наверное, "ну очень быстро" — это когда запрос отрабатывает за выходные?

    За доли секунды.

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

     
     
  • 6.215, bOOster (ok), 06:13, 11/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    - "Упрямство - достоинство ослов"
     
  • 3.70, Аноньимъ (ok), 19:45, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну вот например:

    https://diginomica.com/look-servicenow-managing-85000-databases-25-billion-que

    Вроде всё отлично у них за пределами 10 посетителей в день.

     
     
  • 4.72, kernel (??), 19:50, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    На самом деле, при таких нагрузках у mariadb были проблемы. У меня несколько сотен тысяч баз, и были баги, на которые делал багрепорты. К счастью, все эти багрепорты уже достаточно давно закрыты. Но подебажить пришлось основательно, чтобы разработчики смогли найти причины.
     
  • 3.92, fuggy (ok), 23:42, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На самом деле у MySQL намного больше универсальности чем ожидается. У неё несколько моделей хранения и можно для каждой таблицы выбрать разную. Настоящие физические кластерные индексы. В PostgreSQL же только одна модель хранения, на которую все вечно жалуются что она пухнет. Вот когда добавят минимум ZHeap, тогда и можно говорить об универсальности. Так что популярность PostgreSQL не связана с универсальностью. Скорее с расширяемостью, соблюдением стандартов, скоростью развития.
     
     
  • 4.95, Аноним (180), 00:11, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ^ О, ловите php-шника за $2/час
     
     
  • 5.125, Аноньимъ (ok), 11:31, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > О, ловите php-шника за $2/час

    Поймал тебя дорогой. Полезай в мешок.

     
  • 4.100, Аноним (7), 00:27, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты сам ответил на свой вопрос. Универсальность это плохо.
     
  • 2.71, kernel (??), 19:47, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Странные ваши суждения, работаю и с mysql и с pg. Базы занимают терабайты Использую для разных вещей просто потому, что у них разная архитектура и есть места, где pg выигрывает, есть и где mysql. Но в общем-то, с большинством данных они справляются примерно одинаково. Если, конечно, структуру нормальный инженер проектировал.
     
     
  • 3.76, Аноньимъ (ok), 20:32, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С вами я могу только солглашаться Всегда интересно послушать мнение профессиорн... большой текст свёрнут, показать
     
     
  • 4.83, Аноним (26), 21:22, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Как-то смотрел на PG но обнаружил путь от "установил пакет" до "подключился и работаешь" слишком сложным.

    Весьма наглядная иллюстрация тезиса

    > Типовому PHP-разработчику за $2/час не хочется много думать и что-то учить, ему хочется фигак-фигак и в продакшн.

    Причем, в отсутствие особых требований этот путь может быть нулевым, так как постгрес очень неплохо работает с настройками по умолчанию.

     
  • 4.93, fuggy (ok), 23:57, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL. Лучше поддержка разных типов данных JSON, массивов, енумов. Больше типов индексов, есть частичные, функциональные, индексы для геометрических типов данных. Продвинутое управление ролями, даже есть row level security. Так что плюсы в использовании PostgreSQL есть.
     
     
  • 5.97, Аноним (180), 00:14, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну ок, повысим до php-шника за $8/час
     
  • 5.108, Аноним (108), 05:50, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все эти плюшки нужны только если тащите логику приложения в слой хранения данных.
    Обычно принято дублировать логику. То есть она и в базе, и в приложении. Зачем этот БДСМ нужен, каждый ответит для себя сам.
    У кого-то это способ защиты от написанного джунами кода, у кого-то одержимость контролем всего и вся.
     
     
  • 6.147, fuggy (ok), 15:07, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, а потом будем тянуть тысячи строк в браузер, чтобы по новой изобрести алгоритмы сортировки и джойнов. Не всегда с базой работает только одно приложение. Ещё есть тестировщики и разработчики, которые могут напрямую в бд вставить что-то. И что в каждое приложение добавлять логику ограничений, проверки уникальности, внешние ключи. Есть схема данных и зачем это тащить в логику приложения. Разгребать потом дубликаты и искать проблемы где забыли добавить внешние ключи намного сложнее, чем мнимый выигрыш от того что бд будет работать быстрее, если мы не будем использовать внешние ключи.
     
  • 6.173, Аноним (180), 19:47, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В слое хранения могут быть только данные, а не логика. Логика же это код, выполняемый рядом с данными. И здесь речь идёт не о типах данных и прочих похожих фичах, а о UDF-ках. Нужны они по совершенно очевидной причине: перелопачивание данных прямо в СУБД работает быстрее аналогичной логике на строне клиента (на клиент нужно туда-сюда гонять данные). Этот подход широко используется в биг дате в виде map-reduce и прочих схемах распределённых вычислений. Для OLTP от этого тоже может быть польза на некоторых схемах баз.

    Сами же дополнительные типы данных и индексы тоже помогают ускорять работу. Обычно дублирования логики не делают т.к. завязка на фичи PG больше никуда не переносима и на другой СУБД уже не получится  получить такие же ТТХ эмуляцией логики.

     
  • 5.126, Аноньимъ (ok), 11:43, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Лучше поддержка разных типов данных JSON

    Это зло.

    > PostgreSQL лучше хотя бы тем что там есть check constraint, а не делает вид что они есть как MySQL.

    Разверните.

    > индексы для геометрических типов данных.

    https://mariadb.com/kb/en/geographic-geometric-features/

     
     
  • 6.148, fuggy (ok), 15:40, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению это жизнь и JSON проник везде И иногда проще вставить JSON, чем соз... большой текст свёрнут, показать
     
     
  • 7.150, Аноньимъ (ok), 16:03, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, можно или нельзя. Я не большой сторонник стандартов ради стандартов. И не знаю насколько им следует например МС или Оракл.

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

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

     
     
  • 8.154, fuggy (ok), 17:20, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вообще-то PostgreSQL разрабатывался как объектно-реляционная, не путать с докуме... текст свёрнут, показать
     
  • 7.177, Аноним (180), 20:12, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть простое правило, если с данными работают атомарно (не нужно читать или изменять отдельные поля внутри), то так даже эффективнее хранить в одной колонке.

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

     
     
  • 8.187, fuggy (ok), 23:35, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я про JSON и веду речь Можно создать индекс, но подход немного в другом Что ес... большой текст свёрнут, показать
     
  • 3.81, Аноним (26), 21:11, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Использую для разных вещей просто потому, что у них разная архитектура и есть места, где pg выигрывает, есть и где mysql.

    Прямо даже интересно, в каком месте может выиграть mysql?

     
     
  • 4.106, пох. (?), 00:58, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    миллион inserts/s в базку key-value

     
  • 3.90, Аноним (43), 23:11, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Базы занимают терабайты

    Ну это не серьёзно, уровень sqlite ведь.

    >справляются примерно одинаково

    Ну я и говорю, зачем все эти навороты, когда это задачи для sqlite?

    >структуру нормальный инженер проектировал

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

     
     
  • 4.94, Аноним (26), 00:07, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну это не серьёзно, уровень sqlite ведь.

    Не надо тут, уровень sqlite — не меньше сотни петабайт!

     
     
  • 5.96, Аноним (43), 00:12, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не уверен, там лимит около 250 терабайт. Правда, я не слышал, чтобы кто-нибудь больше ~20 задействовал, но, очевидно, что запас хороший остаётся при этом.
     
  • 2.103, Аноним (103), 00:37, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    тебе, наверное, больше подходит решение от ms, т.к. пишешь на шарпе? И почему нас должна интересовать проприетарщина?
     
     
  • 3.197, Прохожий (??), 13:13, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тебе шашечки или ехать?
     

     ....большая нить свёрнута, показать (56)

  • 1.54, sig11 (ok), 17:52, 04/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А куда делись dBase, FoxPro, Clipper? Да они со своим форматом DBF порвут все эти SQL-и по всем параметрам...
     
     
  • 2.56, Аноним (26), 18:06, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не порвали, поэтому их тут и нет.
     
  • 2.57, Аноним (31), 18:13, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Paradox'а тоже нету.
     
  • 2.74, Аноним (5), 20:05, 04/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Свой вижуал бэйсик проприетарный выкинуть можете.
     
  • 2.170, Аноним (170), 19:31, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Они канули в лету, но что-то мне говорит, что их новая "волна популярности" ещё впереди. Есть мириады мест, где "многопользовательность" нужна сугубо локально, в пределах офиса. Спрашивается, зачем им умопомрачительные по сложности транзакции, блокировки, файловеры, зеркала, когда всё прекрасно работает на уроне 3 конекшенов и SQLite? Другой вопрос, что подход к "файл-ориентированным СУБД" должен быть современный, модульный, масштабный, тогда и реализации появятся очень даже вкусные.
     
     
  • 3.198, adolfus (ok), 17:39, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Два и более одновременно работающих пользователя с базой данных в любом случае требуют блокировок и сериализации доступа, а работа с двумя и более таблицами в любом случае требует ACID-транзакций.
    В противном случае практически сразу базу запорете.
    Не, можно использовать b однопользовательские СУБД, но придется самому реализовывать все алгоритмы "читатели-писатели", семафоры, мьютексы и и прочие сериализационные кунштюки. Но только, если язык вашей субд это позволяет. Инасе придется все операторы вашей СУБД обернуть в функции си или сикрос-крос, чтобы задействовать многопользовательские механизмы posix.
     
     
  • 4.205, Аноним (205), 01:24, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не, не всё так сложно Вернее, некотрые сложности РСУБД можно избежать Класс... большой текст свёрнут, показать
     

  • 1.101, Вы забыли заполнить поле Name (?), 00:32, 05/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    У постгреса все хорошо:

    * опенсорс
    * нормальная лицензия, которая позволяет без проблем делать облачные решения (привет, монго)
    * проверена временем и нагрузками
    * есть специалисты
    * для любителей обмазаться json все есть
    * что не маловажно для РФ, что postgrespro входит в Единый реестр, имеет сертификат ФСТЭК

     
     
  • 2.102, Вы забыли заполнить поле Name (?), 00:33, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Забыл добавить

    * дока отличная
    * расшираяемость отличная
    * написана на божественной сишечке

     
     
  • 3.112, Антонимусс (?), 08:28, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У PostgreSQL настолько все замечательно, что Google год назад получили прирост производительности в 100 (sic!) раз на ровном месте, просто переписав там слой хранения данных. Называется AlloyDB.

    Существует масса паразитических контор, которые льют в уши насколько PG весь такой бесплатный Open Source, а потом стригут с бизнеса бабло за пропитанные патчи, без которых эта шарманка толком не работает.

     
     
  • 4.142, нах. (?), 14:52, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Называется AlloyDB.

    и работает только в специфическом use case гугля.
    Как обычно.

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

    > Существует масса паразитических контор, которые льют в уши насколько PG весь такой бесплатный
    > Open Source, а потом стригут с бизнеса бабло за пропитанные патчи, без которых эта шарманка
    > толком не работает.

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

    Но проблема что сколько ту опенсорсную поделку не корми - у орацла все равно и толще и длиннее.

    И vacuum почему-то не нужон.

     
     
  • 5.184, Антонимусс (?), 22:33, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > работает только в специфическом use case гугля.

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

    > вот видишь - конь-куренция! А у орацла - контора одна, и другого источника патчей у тебя нет

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

    Оракл в ноябре начали предлагать допиленный PG в качестве опции в своем клауде (OCI).

    Короче, хотите нормальный PG - платите.

     
     
  • 6.216, bOOster (ok), 06:25, 11/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, отказываются принимать патчи от таких знатоков как ты? Лечашие одну проблему и создающие десяток других? Нуну..
     
  • 4.162, Аноним (170), 18:44, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я не понимаю, почему плебеи вроде вас (в самом прямом ИТ-смысле как "люди, крутящиеся вокруг самых дешевейших решений") рассуждают о Гугле? Кто вы и кто они - не чувствуете разницу? Гугл, M$, Oracle, Amazon... да даже Stack Overflow НАМНОГО круче, крупнее и мощнее любых ваших проектов. Соотв. с вашей позиции вообще нельзя ничего примерять на себя из того, что творят "столпы ИТ". Ваши два филиала бухгалтерии ПРЕКРАСНО справятся под любой из современных СУБД, нет даже никакого смысла спорить. Кому по вкусу PG - ради бога, ставьте, ОН ТОЖЕ РАБОТАЕТ. Вам гугловские патчи точно не нужны.
     
     
  • 5.186, Антонимусс (?), 22:58, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Кому по вкусу PG - ради бога, ставьте, ОН ТОЖЕ РАБОТАЕТ. Вам гугловские патчи точно не нужны.

    Например. В PG есть счётчик транзакций (XID), который постоянно увеличивается. Когда он переполняется, то вся база встаёт раком. Сбрасывается запуском Vacuum. Он тоже нагибает базу, но временно. В опенсорсной версии размер счетчика 32bit и вам нужен периодический vacuum и как следствие - даунтаймы. Во всех коммерческих форках он уже давно 64 bit (мне кажется это первое, что сразу фиксят), так что с проблемой переполнения вы просто ни когда в жизни не столкнетесь.

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

     
     
  • 6.204, Аноним (205), 00:56, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Увы, долго постгрес не использовал вообще - у меня пока пет-проекты на нём. Но это не отменяет моих слов - у БОЛЬШИХ компаний проблемы вообще несопоставимы с очередным наколенным "Склад-33". А если счётчик транзакций можно перезапустить остановкой сервера, то скорее всего так и будет. Ну то есть для большинства компаний Постгрес - вполне работающая вещь. На крайняк - возьмут MS SQL, не сильно дорогая вещь (вот я с ним во весь рост писал!).
     
  • 2.109, Аноним (108), 05:52, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Все так хорошо, что его надо постоянно навязывать и писать в интернете проповеди о его превосходстве.
     
     
  • 3.159, Аноним (26), 18:10, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То-то все комментарии здесь забиты проповедями про "замечательный mysql", про его простую и прекрасную архитектуру, но без конкретики и вообще подозрительно напоминающие маркетинговую лапшу.
     
  • 3.163, Аноним (170), 18:46, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Никогда такого не слышал. Любые топики про постгрес прекрасно обходятся тем, что люди УЖЕ используют Постгрес и им ДОВОЛЬНЫ. Самая агитутская технология в ИТ - это раст. ВЕЗДЕ где можно влезают со своим недоязыком и постоянно капают в уши "работой с памятью". Можно подумать, это единственная проблема софта!
     
  • 3.189, Вы забыли заполнить поле Name (?), 00:46, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Все так хорошо, что его надо постоянно навязывать и писать в интернете
    > проповеди о его превосходстве.

    Путаешь с растом. Постгресу реклама не нужна.

     
  • 2.164, лютый жабби.... (?), 18:54, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >что не маловажно для РФ, что postgrespro входит в Единый реестр, имеет сертификат ФСТЭК

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

     

  • 1.107, Аноним (108), 05:44, 05/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Mysql лучше уже тем, что проще. И она работает. Большая часть претензий к ней из времён myisam по умолчанию. То есть было актуально двадцать лет назад.
    Да, у большинства пихающих постгрю везде нет и не будет таких данных, чтобы она была прямо необходима. Берут на вырост, чтобы показать главным образом себе, какие они крутые специалисты.
     
     
  • 2.136, Аноним (7), 12:43, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Берут на вырост чтобы не заниматься лишней миграцией из майсикуэль в постгресс.
     
  • 2.144, Аноним (26), 14:57, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Mysql лучше уже тем, что проще. И она работает.

    По обоим критериям проигрывает постгресу.

     

  • 1.110, Аноним (110), 06:07, 05/01/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +2 +/
     

     ....ответы скрыты (7)

  • 1.155, Аноним (155), 17:24, 05/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Десятилетиями работаю с PHP и MySQL. На всяких работах работал, везде MySQL. Только в одной госконторе были oracle, роstgres да и то частично.
     
     
  • 2.161, Аноним (170), 18:32, 05/01/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Сочувствую! Так и не поработал на нормальных СУБД... :(
     
     
  • 3.201, Аноним (201), 23:16, 08/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    и на нормальном ЯП
     

  • 1.199, Аноним (199), 18:27, 06/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Мусор даже не поддерживает пул-потоков из коробки в отличии от МашаДБ.
    md5 аутентификация? Вы серьёзно?
     
     
  • 2.217, bOOster (ok), 09:08, 11/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Серьезно, мозгов тебе не хватило до kerberos авторизации/аутентификации?
     

  • 1.200, Rollo99 (ok), 21:28, 07/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вопрос к знатокам Postgre.
    Есть ли инструмент для восстановления одной конкретной БД на сервере на произвольный момент времени из бекапа без остановки всего инстанса?
    Без развлекухи с ручным поднятием временного инстанса PG, восстановления и выгрузки\загрузки дампа.
     
     
  • 2.202, Аноним (205), 00:50, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ща спросил примерно такую фигню: "А можно открыть книгу "Каштанка", пролистать до середины и на следующей странице чтоб были "Мцыри"?". Ну вот как ты без остановки сменишь базу? Вернее, что тебе даст "работающий инстанс", если ему всё равно придётся сбросить ВСЁ и загрузить бэкап как АБСОЛЮТНО НОВУЮ базу? Ты ничего не выйграешь, что с остановкой, что без.
     
     
  • 3.212, PnD (??), 12:41, 10/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос в целом таки по делу. Будь WAL свой для каждой БД, такой фокус вполне мог бы прокатить "в лоб".
    Но у постгри единое состояние для всех БД одного инстанса. И это, в целом, не самое дурное решение (ресурсы-то общие).

    Я бы посмотрел в сторону новых механизмов репликации. Там вроде появились логи транзакций. И из них можно вытащить то что M$ продаёт последние 20+ лет. Полный бэкап отдельной БД, плюс инкрементный (транзакции с момента полного бэкапа).

    * Возможно даже что у кого-то такое есть готовое. За денюжку.
    Понятно, ценой производительности/места на СХД, в силу архитектурных нюансов.

    ** В моих краях N лет назад приняли решение "не выпускать новые проекты под Oracle DB".
    Старые мигрировать дурных не нашлось. А так, можно постепенно допиливать под свои кейсы. И делать код с учётом известных особенностей постгри. А не "сделайте мне (на шару) 1:1 как в энтерпрайзе за вагон денег".

     

  • 1.206, Аноним (206), 08:06, 09/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Postgres Pro Enterprise Manager уже кто-нибудь использует?
     
  • 1.207, Аноним (207), 08:45, 09/01/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А майкософт уже подключился к "разработке" Postgres ?
     
     
  • 2.208, dmrjan (?), 14:39, 09/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Microsoft уже давно сказал, что PostgreSQL Pro Enterprise конкурентоспособная база данных. С учетом того, что появился Postgres Pro Enterprise Manager, как аналог management studio, то мелкомягкие точно не пропустят этот момент.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру