AG
даже sap в sql-диалект умеет, не только cobol страшный
Size: a a a
2020 June 08
D
зачем? там всё стандартизированно и продукты разных компаний и сообществ более-менее этому стандарту следуют
Я про то что высказывание можно и в обратную сторону. Не объективно жеж
AG
Я про то что высказывание можно и в обратную сторону. Не объективно жеж
нельзя в обратную сторону, никак нельзя ибо неверно будет потому, что см. предыдущий ответ
D
даже sap в sql-диалект умеет, не только cobol страшный
Тоже так себе аргумент. Он делался как учётная система и на идее таблиц строился
D
нельзя в обратную сторону, никак нельзя ибо неверно будет потому, что см. предыдущий ответ
Так нет жеж) аргументов нет, только вкусовщина. Которую можно хоть как сформулировать ( от задач надо идти...
AG
Тоже так себе аргумент. Он делался как учётная система и на идее таблиц строился
а причем тут таблицы?
AG
Так нет жеж) аргументов нет, только вкусовщина. Которую можно хоть как сформулировать ( от задач надо идти...
т.е. слово "стандарт" ни о чем не говорит, да?
D
т.е. слово "стандарт" ни о чем не говорит, да?
Стандарт есть и монги
AG
Стандарт есть и монги
и сколько других продуктов использует этот стандарт?
D
а причем тут таблицы?
Я про то что особенность выставляется за фичу
AG
Я про то что особенность выставляется за фичу
это не фича, это основа
П
Чат, подскажите плиз, как рассчитать хар-ки для реплики, на которой только валы проигрываются и бекапы делаются? На сколько меньше ядер-памяти давать чем на мастере?
wal-receiver однопоточный если не ошибаюсь, много цпу думается не нужно.
От чего плясать короче?)
wal-receiver однопоточный если не ошибаюсь, много цпу думается не нужно.
От чего плясать короче?)
YS
По опыту использования это объективная реальность, отделенная от pgsql евангелизма
Объективная реальность противоположна этому высказыванию.
Но да, "MongoDB is web scale!", по-прежнему. ;)
Но да, "MongoDB is web scale!", по-прежнему. ;)
YS
Чат, подскажите плиз, как рассчитать хар-ки для реплики, на которой только валы проигрываются и бекапы делаются? На сколько меньше ядер-памяти давать чем на мастере?
wal-receiver однопоточный если не ошибаюсь, много цпу думается не нужно.
От чего плясать короче?)
wal-receiver однопоточный если не ошибаюсь, много цпу думается не нужно.
От чего плясать короче?)
> wal-receiver однопоточный если не ошибаюсь,
Да, однопоточный. Так что именно по CPU любого современного севера хватит, казалось бы.
Т.е. лишь бы успевал — а это disk (ну и RAM), в основном. Но Вам бы лучше потестировать на своих нагрузках, конечно...
Да, однопоточный. Так что именно по CPU любого современного севера хватит, казалось бы.
Т.е. лишь бы успевал — а это disk (ну и RAM), в основном. Но Вам бы лучше потестировать на своих нагрузках, конечно...
ВЯ
"по опыту" и "объективно" как то странно использовать вместе)
4
Я бы его если честно закопал и направил сообщество на развитие 1 продукта)
не надо нам тут монополий :)
одного ms уже хватат...
одного ms уже хватат...
E
Всем привет. А подскажите плиз по документации, что-то не могу понять.
https://www.postgresql.org/docs/current/sql-createtable.html
create table xxx2 ( idbt doubleid primary key using gist ( id1 WITH =, id2 with = ), name text);
где doubleid - create type doubleid as ( id1 int, id2 int );
подскажите плиз как задать index_parameters
https://www.postgresql.org/docs/current/sql-createtable.html
UNIQUE ( column_name [, ... ] ) index_parameters |Не получается указать index_parameters и примеров как-то не нахожу ((
PRIMARY KEY ( column_name [, ... ] ) index_parameters |
EXCLUDE [ USING index_method ] ( exclude_element WITH operator [, ... ] ) index_parameters [ WHERE ( predicate ) ] |
...
index_parameters in UNIQUE, PRIMARY KEY, and EXCLUDE constraints are:
[ INCLUDE ( column_name [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) ]
[ USING INDEX TABLESPACE tablespace_name ]
create table xxx2 ( idbt doubleid primary key using gist ( id1 WITH =, id2 with = ), name text);
где doubleid - create type doubleid as ( id1 int, id2 int );
подскажите плиз как задать index_parameters
s
```В 100% случаев задачу можно решить без СУБД вообще... но если с тем же качеством — лет этак через 200. ;)
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Паттерн. ООП - это то же ФП по сути. Объект - есть так же функция высшего порядка. Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Всё, что можно сделать в ООП, может быть написано в ФП. Иногда удобнее ООП, иногда ФП. Но это не значит, что ООП лучше. Он проще, чем ФП, тут да. Джуну ФП будет даваться сложнее. В современных задачах ФП/ООП скорее вкусовщина и квалификация команды.
```Это "синдром" не забивания гвоздей микроскопом. ;) Т.е. RDBMS [намного] лучше решают одни задачи, NoSQL — другие.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
И это, опять-таки, в норме никому не интересно, см. выше.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Google использует MongoDB?
.P
Коллеги, добрый вечер.
Посоветуйте пожалуйста умный мыслей по апгрейду PG с минимальным даунтаймом.
Есть в продакшене hostA, centos6, pg 9.3, база на 200G.
И новый hostB, centos8, pg 12.
Как я понимаю, мне нужно смотреть в сторону Slony, или есть ещё варианты?
*dump не подходит из-за долгого даунтайма, pg_upgrade из-за разных хостов. (как я понял, читая разные статейки)
Посоветуйте пожалуйста умный мыслей по апгрейду PG с минимальным даунтаймом.
Есть в продакшене hostA, centos6, pg 9.3, база на 200G.
И новый hostB, centos8, pg 12.
Как я понимаю, мне нужно смотреть в сторону Slony, или есть ещё варианты?
*dump не подходит из-за долгого даунтайма, pg_upgrade из-за разных хостов. (как я понял, читая разные статейки)
VY
Коллеги, добрый вечер.
Посоветуйте пожалуйста умный мыслей по апгрейду PG с минимальным даунтаймом.
Есть в продакшене hostA, centos6, pg 9.3, база на 200G.
И новый hostB, centos8, pg 12.
Как я понимаю, мне нужно смотреть в сторону Slony, или есть ещё варианты?
*dump не подходит из-за долгого даунтайма, pg_upgrade из-за разных хостов. (как я понял, читая разные статейки)
Посоветуйте пожалуйста умный мыслей по апгрейду PG с минимальным даунтаймом.
Есть в продакшене hostA, centos6, pg 9.3, база на 200G.
И новый hostB, centos8, pg 12.
Как я понимаю, мне нужно смотреть в сторону Slony, или есть ещё варианты?
*dump не подходит из-за долгого даунтайма, pg_upgrade из-за разных хостов. (как я понял, читая разные статейки)
смена ОС влияет, если меняется glibc и сортировка строк.
в принципе, сделать реплику на новой ОС, апгрейднуть её и затем перестроить в первую очередь UNIQUE индексы с ключами, зависящими от glibc, затем остальные индексы — вполне возможно.
помимо слонов, можно смотреть ещё и на londiste — я им предпочитаю тащить данные
в принципе, сделать реплику на новой ОС, апгрейднуть её и затем перестроить в первую очередь UNIQUE индексы с ключами, зависящими от glibc, затем остальные индексы — вполне возможно.
помимо слонов, можно смотреть ещё и на londiste — я им предпочитаю тащить данные