forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Релиз СУБД PostgreSQL 10, opennews (ok), 05-Окт-17, (0) [смотреть все]

Вот и до этих мода на симуляцию развития рисованием красивых цифр дошла , Iaaa (ok), 17:48 , 05-Окт-17, (1) –10 //

Ребята дело делают Пофиг на циферки , h31 (ok), 17:54 , 05-Окт-17, (3) +30
Наоборот, сменили нумерацию на более логичную Бинарная несовместимость данных м, KonstantinB (ok), 18:40 , 05-Окт-17, (6) +18 //

Ага, а потом опять дойдут до версий 50 и решат что слишком много и вернуться обр, фывфыв (?), 22:05 , 05-Окт-17, (18) –1 //

less и systemd возвращаться не собираются, Аноним (-), 00:32 , 06-Окт-17, (20) +1

Правильно, вот и пусть systemd идёт как можно дальше в less , Аноним (-), 09:10 , 06-Окт-17, (45) +7

Эй, вот не надо хотя бы в less свой системде пихать А то чем файлы-то смотреть , Аноним (-), 12:58 , 06-Окт-17, (81)

С таким циклом разработки Postgre SQL 50 выйдет в 2057 году Дожить бы до этого, 1222 (?), 07:25 , 06-Окт-17, (30) +2

офиц пресс-релиз на русском https www postgresql org about press presskit10 , Аноним (-), 17:56 , 05-Окт-17, (4) +1
Хорошая субд для тех кому скорость не нужна, лютый жабист__ (?), 18:33 , 05-Окт-17, (5) –45 //

Сильное заявление, проверять его я, конечно, не буду c Говорить о скорости мо, KonstantinB (ok), 18:42 , 05-Окт-17, (7) +11 //

Is dev null webscale , Maxim Filatov (?), 11:08 , 07-Окт-17, (101) +1 //

No, it s super-trans-hyper-pooper-webscale I , Andrey Mitrofanov (?), 11:13 , 07-Окт-17, (102) +1

Pooper это профессия от слова poop , Аноним (-), 03:40 , 12-Окт-17, (119)

Словарь не тут ---Ж есть, а слова нету , Andrey Mitrofanov (?), 09:52 , 12-Окт-17, (120)

Научись свой код оптимизировать , andy (??), 19:04 , 05-Окт-17, (8) +4 //

Ну соптимизируй мне join чтобы из 20 таблиц собирал аналог Mongo-вского документ, лютый жабист__ (?), 07:12 , 06-Окт-17, (29) –12 //

Соптимизируй обновление этих 20 таблиц в монго, чтобы было устойчиво к сбоям и н, Агроном (?), 07:31 , 06-Окт-17, (32) +4

Батя, не выставляй себя на посмешище, в Монго это будет одна таблица Почитай пр, лютый жабист__ (?), 08:01 , 06-Окт-17, (36) –7

Имеется ввиду непротиворечивое обновление 20 документов , Агроном (?), 08:59 , 06-Окт-17, (40)

Для одаренных В МОНГЕ ЭТО ОДИН ДОКУМЕНТ , лютый жабист__ (?), 09:07 , 06-Окт-17, (43) –2

У тебя вся БД 8212 один документ Ну рад за тебя , Аноним (-), 13:01 , 06-Окт-17, (82) +3

Ни разу не пользовался монгой и решил посмотреть что же у них за data model така, evkogan (?), 09:13 , 06-Окт-17, (46) +5

Не только эксперт по СУБД, сегодня впервые почитавший про mongo, ещё и Телепат , лютый жабист__ (?), 09:20 , 06-Окт-17, (47) –4

В отличие от местных фанатиков, которые лепят ВСЁ Фанатиком не являюсь, но счита, evkogan (?), 09:53 , 06-Окт-17, (48) +1
почитал Действительно интересно Но прямо в этой версии добавили логическую реп, evkogan (?), 10:47 , 06-Окт-17, (54) +1

Фраза была ПГ хорошая, но тормозная СУБД Кстати, с Оракле у меня опыта даже п, лютый жабист__ (?), 11:18 , 06-Окт-17, (58) –3

На всю ту воду, что ты тут льешь, могу только посоветовать выровнять руки Топор, кверти (ok), 12:39 , 06-Окт-17, (77) +2
Хорошо, что ты не Надежда , Led (ok), 19:06 , 11-Окт-17, (118)

Используйте под задачи профильные средства их решения Автомобили тоже хуже само, _KUL (ok), 09:09 , 06-Окт-17, (44) +2
Nikolay Shestakov Подход обозначенный Вами либо вытекает из вашего непрофессиона, Руби Род (?), 09:57 , 06-Окт-17, (49) +4

1 В первом случае Монгу не тестили, хотя костыль под названием ORM это как раз , лютый жабист__ (?), 10:11 , 06-Окт-17, (50) –4

Да, в первом случае MongoDB не тестили ибо тогда 2008 год про такую СУБД еще н, Руби Род (?), 11:11 , 06-Окт-17, (56) +3

которые я решаю на Монго А есть задачи которые я решаю НЕ на монго И вообще, лютый жабист__ (?), 11:39 , 06-Окт-17, (60) –3

1 Вот твои слова Приделываю ORM, скорость из под плинтуса переползает вообще н, Руби Род (?), 11:47 , 06-Окт-17, (62) +1

Современному программисту с ООП головного мозга - безусловно 8 Некоторые ретро, лютый жабист__ (?), 12:04 , 06-Окт-17, (67) –3

Современному погромисту с жабой головного мозга лучше вообще молчать Молчать и , кверти (ok), 12:44 , 06-Окт-17, (78) +2
А скорость работы конечного продукта , angra (ok), 12:58 , 06-Окт-17, (80) +1

Ты из клованов орущих ооп тормозит111 От правильного ооп прога только быстрее, лютый жабист__ (?), 17:16 , 07-Окт-17, (103) –2

Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10 на скорость и объем, angra (ok), 01:08 , 08-Окт-17, (109)
Сказки-с В жабке Integer занимает 40-70 БАЙТ Смотря какой режим, ггггПро орм -, лютый жабист__ (?), 11:33 , 08-Окт-17, (110) –2
То есть ты пытаешься мне доказать, что ООП дает штраф не в 10 , а все 1000 Ну , angra (ok), 12:32 , 09-Окт-17, (112)
Это не отменяет того факта, что жабка номер один везде, кроме опеннета 8 Совер, лютый жабист__ (?), 07:21 , 10-Окт-17, (115) –2
Ты из престарелых ДБА Неужели в 2017-м году ещё кто-то не в курсе, что это реля, лютый жабист__ (?), 13:34 , 08-Окт-17, (111) –2
Я тебе сейчас очень страшную вещь скажу, только ты присядь ООП тоже очень плохо, angra (ok), 12:45 , 09-Окт-17, (113) +2
Ну и глупость пишешь Ты из тех спецов по ООП у которых прям настоящее наследо, лютый жабист__ (?), 07:26 , 10-Окт-17, (116) –2

У нас шардинг кластер монги на 1 3Тб Действительно, если канал между серверами , SunXE (ok), 17:48 , 07-Окт-17, (104)

Положи свой документ в колонку BSON и живи спокойно , Вася (??), 11:51 , 06-Окт-17, (65)

Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги на 1меговых объектах Н, лютый жабист__ (?), 12:06 , 06-Окт-17, (68) –2

Просто неасилятор и профан в postgres, а так же фигляр и позёр по жизни Вот и в, anonymous (??), 13:01 , 06-Окт-17, (83) +1

gt оверквотинг удален Чего-чего -D они там в монге своей добавили хотя бы , Аноним (-), 13:44 , 06-Окт-17, (85)

давай сюда пример инвалидного json, который съест монга 3 4 или 3 2, а то сам зн, лютый жабист__ (?), 16:21 , 06-Окт-17, (88) –1

Жабист в нике объясняет такое мнение - Если рассматривать СУБД чисто как сло, KonstantinB (ok), 19:21 , 06-Окт-17, (90) +2
Хоспыдя хипстеры, откуда вы лезете-то фэйспалм Из подвёрнутых штанов Сид, Kodir (ok), 00:56 , 08-Окт-17, (107) –1

Хорошая БД для тех, кому нужна надежность Ну а для сайтиков есть все остальное,, Отражение луны (ok), 19:16 , 05-Окт-17, (9) //

И, вместе с тем, это 8212 БД, которой никогда не было удобно пользоваться , KroTozeR (ok), 21:36 , 05-Окт-17, (17) –4
Ну-ну На моей памяти совсем недавно проскакивали багфиксы в духе ой, мы при не, лютый жабист__ (?), 07:05 , 06-Окт-17, (28) –1 //

Это ты так бесишься потому что все с java на go переходят, а в go ты ничего не с, Аноним (-), 20:27 , 06-Окт-17, (93) +2

На go Люто проиграл с этого Казалось, что на go переходят только php и python , Павел (??), 21:19 , 10-Окт-17, (117) –1

А MongoDB вообще не работала , Аноним (-), 20:36 , 06-Окт-17, (96)

Ты правда такой или прикидываешься Джепсены тестят момент переключения мастер-с, лютый жабист__ (?), 10:11 , 07-Окт-17, (100) –3

А сам ты правда такой или прикидываешься MongoDB фейлила, причём не раз и продо, Аноним (-), 01:04 , 08-Окт-17, (108)

LOL, rshadow (ok), 19:19 , 05-Окт-17, (10)
Релиз СУБД PostgreSQL 10, Michael Shigorin (ok), 19:49 , 05-Окт-17, (11) +12
Зависит от объема данных Или вам больше по душе снежный ком MySQL , Аноним (-), 20:53 , 05-Окт-17, (13) //

Нет, не зависит Full table scan, 30 млрд записей, 600-800 мсек Нужно только ду, ACCA (ok), 21:06 , 05-Окт-17, (15) –6 //

Если запись длиной хотя бы в 70 байт, то это три терабайта в секунду, что на чет, angra (ok), 02:15 , 06-Окт-17, (24) +4

Может он на ram disk какой выгружает это барахло предварительно Но durability б, Мимо проходил (?), 10:24 , 06-Окт-17, (52)

3 ТБ с даже для оперативки овердохрена, не говоря уж о том, что прочитанные данн, Аноним (-), 12:08 , 06-Окт-17, (69) +1

Шардинг же таблица раскидана на 100 серверов , ыы (?), 19:46 , 06-Окт-17, (92) –1

Об этом и речь - головой нужно думать, если у тебя есть нормальный инструмент in, ACCA (ok), 16:42 , 12-Окт-17, (121) –1

Близко Оракл же , iPony (?), 05:05 , 06-Окт-17, (27) –1

Скорость ты сравнивал по select count , полагаю И не учитывал спец сборки в, ACCA (ok), 21:04 , 05-Окт-17, (14) –1 //

Это известный эксперт по замерам Его линейка длинее У него даже grep тормозит , Andrey Mitrofanov (?), 22:38 , 05-Окт-17, (19) +3 //

Чорд У него опять обострилось сравнения тёплого с мягким по дюймовой линейке, в, Andrey Mitrofanov (?), 12:23 , 06-Окт-17, (74) +1

XL или XC А то Коичи там кучу проектов нафоркал, который настоящий - без поллит, YetAnotherOnanym (ok), 00:51 , 06-Окт-17, (22) +2 //

Форка на форке, а в итоге толку ноль все сами себе буратины , Гнилой Бутират и его Поле чудес (?), 03:06 , 06-Окт-17, (26) –1

Моя основная рабочая база 1 3ТБ всего, монга прекрасно тянет и на одном сервере,, лютый жабист__ (?), 08:07 , 06-Окт-17, (37) –4 //

Не корректно сравнивать SQL и noSQL СУБД Всё таки всё зависит от контекста испол, 1222 (?), 08:57 , 06-Окт-17, (39) +1

Ртутные коктейли урановым ломом , Аноним (-), 12:10 , 06-Окт-17, (70)

Железные же, всплывают , Аноним (-), 12:26 , 06-Окт-17, (76) +2

Мне вот просто интересно, откуда у вас такие базы по терабайту Что вы в них хра, Бронтозавр (?), 10:13 , 06-Окт-17, (51)

Уровень экспертов опеннета налицо 20-50ТБ это объём ERP-базки не самой большой , лютый жабист__ (?), 11:12 , 06-Окт-17, (57) –2

2007 15 PetaBytes of new data each year stored http www-conf slac stanford , Andrey Mitrofanov (?), 11:50 , 06-Окт-17, (64) +1
Вы бы не могли назвать эту контору а так же каким образом были получены вами св, ыы (?), 19:34 , 06-Окт-17, (91) –1

Мусохранск-нефтегаз Знаю, сколько стораджа сапёрам дали Уже больше 20, хотя да, лютый жабист__ (?), 10:06 , 07-Окт-17, (99) –1

И откуда такая уверенность что на этом сторадже лежит именно ERP база , ыы (?), 19:33 , 07-Окт-17, (106) –1

Надо понимать, что если в базе хранится что-нибудь специфическое, то что именно , Да аноним (?), 11:39 , 06-Окт-17, (59) –1

15 PetaBytes CD stack with 1 year LHC data 20 Km --стр 14 http openl, Andrey Mitrofanov (?), 12:13 , 06-Окт-17, (71) +1

Старый очень анекдот на эту тему Спорят 2 программиста - Уменя программа раб, Агроном (?), 07:43 , 06-Окт-17, (34) +2 //

Самый смех в том, что Pg не только медленнее, ещё и работает неправильно Я что-, лютый жабист__ (?), 08:21 , 06-Окт-17, (38) –3 //

Интересное чтиво https habrahabr ru company southbridge blog 322624 Из эпичног, лютый жабист__ (?), 09:03 , 06-Окт-17, (41) –1
Переключалка через pacemaker отлично работает , Мимо проходил (?), 10:30 , 06-Окт-17, (53) –1

А без Shared Storage А то так можно сказать что репликацию поддерживает и SQLit, лютый жабист__ (?), 11:06 , 06-Окт-17, (55)

https www youtube com watch v SNzOZKvFZ68, anonymous (??), 12:47 , 06-Окт-17, (79)
https jira mongodb org browse SERVER-2237 jql issuetype 20 3D 20Bug 20AND 20te, OhBoyHereWeGo (?), 13:18 , 06-Окт-17, (84) +2

Huge data loss after altering files in dbpath on a running instanceЭто баг в моз, лютый жабист__ (?), 16:18 , 06-Окт-17, (87) –2

https aphyr com posts 322-jepsen-mongodb-stale-reads, Аноним (-), 20:33 , 06-Окт-17, (94)
In this Jepsen analysis, we develop new tests which show the MongoDB v0 replicat, Аноним (-), 20:34 , 06-Окт-17, (95)
Да, с версии v3 4 наконец перестали самопроизвольно реплики вылетать в unrecover, SunXE (ok), 18:03 , 07-Окт-17, (105)

Расскажи нам опять, что монга круче справиться , лютей лютого жабиста__ (?), 11:56 , 06-Окт-17, (66)

Презентация к релизу https postgrespro ru media 2017 10 05 postgres-10-hse-201, Catwoolfii (ok), 20:19 , 05-Окт-17, (12) +2
На сайте пока не даёт выбрать 10 для загрузки Для Centos 7 можно установить так , Casm (??), 21:12 , 05-Окт-17, (16) –2
ClickHouse, RocksDB быстрее PgSQL дрянных хранилок, DRM (?), 00:41 , 06-Окт-17, (21) –1 //

ClickHouse - колоночная база RocksDB - встраиваемая библиотека для key-value Что, KonstantinB (ok), 02:06 , 06-Окт-17, (23) –1 //

Thread pool из коробки тоже нету, DRM (?), 02:55 , 06-Окт-17, (25)
Это где таблицы с инверсным хранением Можно подобрать случаи, когда такой подхо, Агроном (?), 07:39 , 06-Окт-17, (33)

Таких имен тысячи Узкоспециализированных продуктов под какой-то тип данных и ти, Вареник (?), 07:27 , 06-Окт-17, (31)
ClickHouse разве не append-only , Да аноним (?), 09:04 , 06-Окт-17, (42) //

Он ещё и не совсем ACID Зато заточен под стат расчёты по очень-очень плотно , PnD (??), 11:47 , 06-Окт-17, (63)

Декларативное партиционирование таблиц разделяйте ваши данные с лёгкостью Эх , Abu (?), 11:46 , 06-Окт-17, (61) –2 //

Тише-тише, не так скоро Сначала с 8 3 надо слезьть ну, с 9 1, ладно, Andrey Mitrofanov (?), 12:16 , 06-Окт-17, (72) //

все равно - чую приближение весны , abu (?), 04:41 , 07-Окт-17, (97) –1

и использовать pgAdmin в качестве эмулятора терминала, Штунц (?), 17:28 , 06-Окт-17, (89) –2
https www youtube com watch v b2F-DItXtZs, Аноним (-), 09:30 , 07-Окт-17, (98)
Комитом унитазы моют А БД -- транзакции ФИКСИРУЮТ , Аноним (-), 15:19 , 09-Окт-17, (114) –3

Сообщения [Сортировка по времени | RSS]

29. "Релиз СУБД PostgreSQL 10" –12 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 07:12

>> Хорошая субд для тех кому скорость не нужна
> Научись свой код оптимизировать.
Ну соптимизируй мне join чтобы из 20 таблиц собирал аналог Mongo-вского документа хотя бы в 10 раз медленнее? А то пока что все 50 получается.
Про JSONB/JSON не надо, функционала по сравнению с полноценной документной субд с гулькин гуль и при этом тормознее.
Итого, "Хорошая субд для тех кому скорость не нужна"
Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но зато уже хоть удобно что-то делать на ней.
p.s. Да, я знаю usecase-ы где Слон быстрее Монги. Полнотекстовый поиск и "вытащить только пару полей из большого документа". Но жабовский полнотекстовый поиск ещё быстрее и продвинутее оказался, по второй проблеме - пока терпим. Как обойти тоже понятно. В остальном сплошнейшие плюсы.

Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз СУБД PostgreSQL 10" +4 +/–

Сообщение от Агроном (?), 06-Окт-17, 07:31

Соптимизируй обновление этих 20 таблиц в монго, чтобы было устойчиво к сбоям и не оставляло БД в противоречивом состоянии, если что пошло не так. И чтобы это было хотябы в 10 раз медленее нормальной субд.

Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз СУБД PostgreSQL 10" –7 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 08:01

>Соптимизируй обновление этих 20 таблиц в монго,
Батя, не выставляй себя на посмешище, в Монго это будет одна таблица. Почитай про mongo data model, прежде чем комментировать.
Какие проблемы с противоречивостью тебе померещились? В Монге все операции над документом атомарны, в том числе всякие прикольные навроде fineOneAndDelete или update с включенным upsert. А в РСУБД надо лепить транзакции и опять ТОРМОZZZzzzzzzzZZZZZа. Хотя, вы привыкшие, не замечаете :))))))

Ответить | Правка | Наверх | Cообщить модератору

40. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от Агроном (?), 06-Окт-17, 08:59

Имеется ввиду непротиворечивое обновление 20 документов.

Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 09:07

Для одаренных: В МОНГЕ ЭТО ОДИН ДОКУМЕНТ.

Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз СУБД PostgreSQL 10" +3 +/–

Сообщение от Аноним (-), 06-Окт-17, 13:01

> Для одаренных: В МОНГЕ ЭТО ОДИН ДОКУМЕНТ.
У тебя вся БД — один документ? Ну рад за тебя.

Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз СУБД PostgreSQL 10" +5 +/–

Сообщение от evkogan (?), 06-Окт-17, 09:13

Ни разу не пользовался монгой и решил посмотреть что же у них за data model такая волшебная.
https://docs.mongodb.com/manual/core/data-model-design/
И тут оказывается, что их 2-е: Embedded Data Models и Normalized Data Models.
Если под Ваши задачи Вам хватает Embedded Data Models и нужна скорость, то монго Ваш выбор.
Но то что Вы даже не понимаете, что полно задач где нужна нормализация говорит только кто выставил себя на посмешище и ставит под сомнение остальные Ваши утверждения.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

47. "Релиз СУБД PostgreSQL 10" –4 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 09:20

>Вы даже не понимаете, что полно задач где нужна нормализация
Не только эксперт по СУБД, сегодня впервые почитавший про mongo, ещё и Телепат? Я вот прекрасно понимаю где Монга не нужна и использую там другие решения. В отличие от местных фанатиков, которые лепят ВСЁ на РСУБД. При этом получая тормоза и MVCCшные глюки. Почитай как всё клёво с Слоне с репликацией и надежностью хранения:
https://habrahabr.ru/company/southbridge/blog/322624/

Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз СУБД PostgreSQL 10" +1 +/–

Сообщение от evkogan (?), 06-Окт-17, 09:53

В отличие от местных фанатиков, которые лепят ВСЁ
> на РСУБД. При этом получая тормоза и MVCCшные глюки.
Фанатиком не являюсь, но считаю что для общих случаев, лучше подходит полноценная РСУБД.
А применять все NoSQL надо там где нужно и не больше.
Про надежность, ошибки бывают у всех. И то что есть их исправление в логах это хорошо. А то что в ченджлоге такого нет, не говорит о отсутствии ошибок.
И да у нас все на Оракле все еще, но в свете импортозамещения по постгре посматриваем, пока издали.

Ответить | Правка | Наверх | Cообщить модератору

54. "Релиз СУБД PostgreSQL 10" +1 +/–

Сообщение от evkogan (?), 06-Окт-17, 10:47

> Почитай как всё клёво с Слоне с репликацией и надежностью хранения:
> https://habrahabr.ru/company/southbridge/blog/322624/
почитал. Действительно интересно. Но прямо в этой версии добавили логическую репликацию. Может и по мотивам этой статьи. Так что дело движется. Хотя насколько я понимаю ни у Постгри, ни у Марии нормальной репликации нет. Есть разные поделки поверх. Каждая из которых под свою задачу. Что ж репликация бывает разной и возможно и правда нужны разные реализации, хотя лучше если они в официальной версии, а не поделка сверху. Тем не менее это не говорит, о том что везде надо применять NoSQL и в частности Монгу. То что в какой-то СУБД в каких-то версиях была ошибка приводящая к возможному повреждению данных при репликациях, не говорит о надежности NoSQL.

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

58. "Релиз СУБД PostgreSQL 10" –3 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 11:18

> Тем не менее это не говорит, о том что везде надо применять NoSQL и в частности Монгу.
Фраза была "ПГ хорошая, но тормозная СУБД". Кстати, с Оракле у меня опыта даже поболее, чем со Слоном. Производительность можно ещё в 1.5-2 раза делить :) а уж костыльность и замшелось просто бесконечны.
Я бы лично хотел оказаться в будущем, где NOSQLей победят объектные СУБД. ObjectDB по описанию тортище. Но небесплатный...
> То что в какой-то СУБД в каких-то версиях была ошибка приводящая к возможному повреждению данных при репликациях, не говорит о надежности NoSQL.
Надежда умирает последней.

Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз СУБД PostgreSQL 10" +2 +/–

Сообщение от кверти (ok), 06-Окт-17, 12:39

На всю ту воду, что ты тут льешь, могу только посоветовать выровнять руки. Топором.

Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от Led (ok), 11-Окт-17, 19:06

> Надежда умирает последней.
Хорошо, что ты не Надежда.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

44. "Релиз СУБД PostgreSQL 10" +2 +/–

Сообщение от _KUL (ok), 06-Окт-17, 09:09

Используйте под задачи профильные средства их решения. Автомобили тоже хуже самолётов летают.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

49. "Релиз СУБД PostgreSQL 10" +4 +/–

Сообщение от Руби Род (?), 06-Окт-17, 09:57

Nikolay Shestakov:
Подход обозначенный Вами либо вытекает из вашего непрофессионализма, либо является простым троллингом. Так или иначе, расскажу свое мнение.

1. Несколько лет назад участвовал в разработке проекта со сложной логикой на стороне сервера приложения. База данных использовалась в качестве простого реляционного хранилища и взаимодействие с ней было реализовано через ORM Hibernate. Поддерживаемыми СУБД были MS SQL, Oracle и Postgres. Мы проводили нагрузочное тестирование на базе размером около 500Gb на не топовых серверах (памяти было толи 32Gb, то ли 64Gb. Точно не больше). Сервер приложений и СУБД находились на разных серверах. Нагрузка подавалась эмитацией работы реального пользователя через силениум (были несколько базовых сценариев работы пользователи и мы их полностью воспроизводили). Так вот: самой быстрой базой при нашем профиле использования оказалась MS SQL, а Oracle и Postgres были примерно одинаковыми (разрыв не превышал 10% от самой "быстрой" и самой "медленной" БД).
2. На текущем месте работы мы пытались использовать MongoDB в нескольких проектах.
В одном из них размер базы около 250Gb (около 150M записей в одной таблице). База шардирована и реплицирована.
При эксплуатации MongoDB такого объема возникла проблема с добавлением новых нод: на ребалансеровку шардов стало уходить до нескольких недель. В итоге конкретно в этом проекте от использования MongoDB отказались.
При этом MongoDB продолжает использоваться в проектах где объем базы гораздо меньше.
3. Так получилось, что нам приходится для анализа хранить логи за последние 3 года (а в некоторых проектах и дольше). Ежедневный размер логов только сервиса в разработке которого принимаю участие я около 30Gb. Итого за три года 3*365*30Gb ~ 32Tb. При этом по этим логам периодически считается всякая статистика.
Ни postgresql ни MongoDB для этой задачи не подходят. Для хранения логов мы используем хранилище с возможностью выполнения Map/Reduce .

Как можно догадаться,
* в первом примере хорошо себя показывает Postgres, и совершенно не пригодны ни MongoDB, ни Map/Reduce;
* во втором примере есть как удачный опыт использования MongoDB, так и неудачный;
* в третьем не подходит ни MongoDB, ни Postgres.
Так, что не надо говорить, что одна база лучше другой, а надо говорить, что в конкретно этой задаче база такая-то показала себя лучше чем база такая-то.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

50. "Релиз СУБД PostgreSQL 10" –4 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 10:11

1. В первом случае Монгу не тестили, хотя костыль под названием ORM это как раз попытки сделать из РСУБД Монгу (только очень тормозную). А можно просто взять быстрый Монго.
2. Про шарды ничего не скажу, хватает одного сервера с 1.3ТБ данных, ничего не тормозит. А репликация очень быстрая, за день с нуля синхронизируется на обычном эзернете.
Случай три: map/reduce в Монго как раз есть.
Итого, либо ДРЕВНЯЯ писулька про Монгу 2.х, либо ламер писал.
В целом наблюдение: все рсудб уже давно в периоде стагнации, ничего путнего не добавляется, либо добавляется криво. Как например графы и json к слону, скорость как у черепахи Тортиллы.
А носкли и в частности Монго развиваются семимильными шагами. Плюс, из-за более узкой специализации разрывают универсальные решения в виде рсубд.

Ответить | Правка | Наверх | Cообщить модератору

56. "Релиз СУБД PostgreSQL 10" +3 +/–

Сообщение от Руби Род (?), 06-Окт-17, 11:11

Да, в первом случае MongoDB не тестили ибо тогда (2008 год) про такую СУБД еще никто не слышал.
Не отрицаю, что я ламер в документо-ориентированных СУБД, это точно подмечено.
Но зато у меня есть достаточно большой опыт в реляционных СУБД и некоторый опыт в Map/Reduce (и да, не на MongoDB).
А вот на ORM Hibernate наезд был абсолютно зря:
1) Для документо-ориентированных СУБД тоже существуют свои ORM, например, OMG от тогоже Hibernate, а это значит, что с документо-ориентированными СУБД тоже есть класс задач, где проще отдать часть операции прослойке, а не делать самому.
2) Hibernate занимается вполне понятной задачей: отображает результат выполнения SQL запроса на объекты (и да, немного упрощает обновление данных и кеширование)
3) Избавляет от необходимости самому учитывать мелкие особенности каждой из поддерживаемой СУБД.
И из последнего Вашего предложения вытекает, что узкоспециализированное решение MongoDB, хорошо подходит к задачам которые Вы решаете. А все ваши наблюдения про РСУБД - это ваши наблюдения в проекции решения ваших задач. В рамках задач решаемых мной, развитие РСУБД, в частности, postgres продолжается, и продолжается весьмы активно.

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз СУБД PostgreSQL 10" –3 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 11:39

> И из последнего Вашего предложения вытекает, что узкоспециализированное решение MongoDB,
> хорошо подходит к задачам которые Вы решаете.
...которые я решаю на Монго. А есть задачи которые я решаю НЕ на монго. И вообще, если уж связываться с РСУБД, то я всеми руками за ORM (можно было не распинаться).
Изначальный тезис был: "Постгрес (и другие рсубд) тормоз". Его люто минусуют, но сказать в ответ нечего 8))))

Ответить | Правка | Наверх | Cообщить модератору

62. "Релиз СУБД PostgreSQL 10" +1 +/–

Сообщение от Руби Род (?), 06-Окт-17, 11:47

1) Вот твои слова "Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но зато уже хоть удобно что-то делать на ней."
Из этой фразы вытекает, что пользоваться РСУБД без ORM неудобно.
2) РСУБД медленны при решении твоих задач, и надо тогда так и говорить, что в такой-то задаче РСУБД медленнее MongoDB, а не голословно утверждать, что РСУБД всегда медленнее MongoDB.

Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз СУБД PostgreSQL 10" –3 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 12:04

>пользоваться РСУБД без ORM неудобно
Современному программисту с ООП головного мозга - безусловно. 8) Некоторые ретрограды не признают ООП, не признают ОРМ, сидят себе пишут SQL-запросы от звонка до звонка. Скорость разработки ниже плинтуса.

Ответить | Правка | Наверх | Cообщить модератору

78. "Релиз СУБД PostgreSQL 10" +2 +/–

Сообщение от кверти (ok), 06-Окт-17, 12:44

Современному погромисту с жабой головного мозга лучше вообще молчать. Молчать и слушать, что говорят.

Ответить | Правка | Наверх | Cообщить модератору

80. "Релиз СУБД PostgreSQL 10" +1 +/–

Сообщение от angra (ok), 06-Окт-17, 12:58

> Скорость разработки ниже плинтуса.
А скорость работы конечного продукта?

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

103. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 07-Окт-17, 17:16

Ты из клованов орущих "ооп тормозит111". От правильного ооп прога только быстрее 8)))

Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от angra (ok), 08-Окт-17, 01:08

Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10% на скорость и объем, а в ORM, который очень плохо ложится на SQL и либо заставляет тратить еще больше времени на оптимизацию по сравнению с написанием чистого SQL, либо спокойно может дать замедление на порядки в отдельных случаях.

Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 08-Окт-17, 11:33

> Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10%
Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг

Про орм - оно может и выигрыш давать, от рук зависит. Но монга как раз рулит там всё без сюрпризов - быстрее и орм и голого скуля в разы. Поэтому сейчас 50% проектов на носклях, 40% орм. 10% хипсторский скуль 8))

Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от angra (ok), 09-Окт-17, 12:32

> Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг
То есть ты пытаешься мне доказать, что ООП дает штраф не в 10%, а все 1000%. Ну окей, верю, что в жабке это так, но я говорил про ООП в нормальных языках.
> Про орм - оно может и выигрыш давать, от рук зависит.
Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL запросы, то ORM может иногда эту кривизну компенсировать.

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

115. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 10-Окт-17, 07:21

>> Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг
> То есть ты пытаешься мне доказать, что ООП дает штраф не в
> 10%, а все 1000%. Ну окей, верю, что в жабке это
> так, но я говорил про ООП в нормальных языках.
Это не отменяет того факта, что жабка номер один везде, кроме опеннета. 8))
>> Про орм - оно может и выигрыш давать, от рук зависит.
> Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL
> запросы, то ORM может иногда эту кривизну компенсировать.
Совершенно неправильно, ORM кривизну не компенсирует. Максимальный профит от ORM когда прогер знает SQL и ORM, но его избавляют от рутины.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

111. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 08-Окт-17, 13:34

> ORM, очень плохо ложится на SQL
Ты из престарелых ДБА? Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку. Соответственно, с самописным ДАО ничего не меняется, надо так же д вприсядку. А уж рефакторинг превращается в лютый гемор, в отличие от ОРМ.
В итоге, правильный подход: девелопим продукт с ОРМ, потом если развитие ОСТАНОВЛЕНО (что почти никогда не бывает), можно выкинуть ОРМ. Но в прямых руках это не даст и нескольких процентов выигрыша. Соответственно, почти никто не делает.

Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз СУБД PostgreSQL 10" +2 +/–

Сообщение от angra (ok), 09-Окт-17, 12:45

> Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку.
Я тебе сейчас очень страшную вещь скажу, только ты присядь. ООП тоже очень плохо ложится на реальность. Листок бумаги с буковками не имеет методов, он не умеет сам ничего делать. И скрепленные или подшитые такие листочки, образующие документ, тоже не умеют сами по себе ничего делать, даже добавить новые листочки. Аналогично с папкой, в которой лежат документы и шкафом, где хранятся эти папки. Все они не умеют делать ровным счетом ничего. Это данные, но без методов. Вот такая вот суровая реальность. А вот схема работы реляционных БД, в которой есть СУБД(библиотекарь, секретарь) и собственно БД(шкафы, полки, папки, каталоги для индексации) почему-то очень реальность напоминает. Может потому, что с нее писалась.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

116. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 10-Окт-17, 07:26

>> Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку.
> Я тебе сейчас очень страшную вещь скажу Листок бумаги с буковками не имеет
> методов, он не умеет сам ничего делать.
Ну и глупость пишешь. Ты из тех "спецов" по ООП у которых прям настоящее наследование на struct-ах делается.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

104. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от SunXE (ok), 07-Окт-17, 17:48

У нас шардинг кластер монги на 1.3Тб. Действительно, если канал между серверами слабый, то синкнуть реплеку простым добавленим сервера очень долго, так что оплог может закончится. Лучшим способом является залочить одну из реплек на запись и тупо скопировать файлы rsync-м с сжатием при копировании. Но это всё максимум сутки, несколько недель это какая-то фантастическая цифра. Никакого оплога на такое не хватит, звучит как то что вы придумали эту цифру.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

65. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от Вася (??), 06-Окт-17, 11:51

Положи свой документ в колонку BSON и живи спокойно.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

68. "Релиз СУБД PostgreSQL 10" –2 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 12:06

>Положи свой документ в колонку BSON и живи спокойно.
Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги на 1меговых объектах.
На маленьких не тестил, но полагаю, что ничего похожего на 100к/сек не будет.
Про неудобство работы молчу. Местами монговский контейнер BSON даже удобнее родных объектов. Слон НИЧЕГО подобного не предлагает.

Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз СУБД PostgreSQL 10" +1 +/–

Сообщение от anonymous (??), 06-Окт-17, 13:01

>>Положи свой документ в колонку BSON и живи спокойно.
> Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги
> на 1меговых объектах.
> На маленьких не тестил, но полагаю, что ничего похожего на 100к/сек не
> будет.
> Про неудобство работы молчу. Местами монговский контейнер BSON даже удобнее родных объектов.
> Слон НИЧЕГО подобного не предлагает.
Просто неасилятор и профан в postgres, а так же фигляр и позёр по жизни. Вот и весь разговор.

Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз СУБД PostgreSQL 10" +/–

Сообщение от Аноним (-), 06-Окт-17, 13:44

>[оверквотинг удален]
> 50 получается.
> Про JSONB/JSON не надо, функционала по сравнению с полноценной документной субд с
> гулькин гуль и при этом тормознее.
> Итого, "Хорошая субд для тех кому скорость не нужна"
> Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но
> зато уже хоть удобно что-то делать на ней.
> p.s. Да, я знаю usecase-ы где Слон быстрее Монги. Полнотекстовый поиск и
> "вытащить только пару полей из большого документа". Но жабовский полнотекстовый поиск
> ещё быстрее и продвинутее оказался, по второй проблеме - пока терпим.
> Как обойти тоже понятно. В остальном сплошнейшие плюсы.
Чего-чего ?! :-D они там в монге своей добавили хотя бы валидацию json при добавлении документов ? или до сих пор вставляй что угодно, а потом map/reduce валится (ни о каких зачатках ACID речи ясное дело не идет)

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

88. "Релиз СУБД PostgreSQL 10" –1 +/–

Сообщение от лютый жабист__ (?), 06-Окт-17, 16:21

> Чего-чего ?! :-D они там в монге своей добавили хотя бы валидацию
> json при добавлении документов ? или до сих пор вставляй что
> угодно, а потом map/reduce валится (ни о каких зачатках ACID речи
> ясное дело не идет)
давай сюда пример инвалидного json, который съест монга 3.4 или 3.2, а то сам знаешь кто.

Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз СУБД PostgreSQL 10" +2 +/–

Сообщение от KonstantinB (ok), 06-Окт-17, 19:21

"Жабист" в нике объясняет такое мнение. :-)
Если рассматривать СУБД чисто как слой персистенции, и вся работа с оной сводится к fooRepository.find(id) и fooRepository.store(entity) - тогда, конечно, РСУБД не только не нужна, но и мешает из-за impedance mismatch. Тут, конечно, любое документное хранилище подойдет лучше.
Но это вообще не та задача, для которой РСУБД задумывались.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

107. "Релиз СУБД PostgreSQL 10" –1 +/–

Сообщение от Kodir (ok), 08-Окт-17, 00:56

> ...Mongo-вского документа
Хоспыдя... хипстеры, откуда вы лезете-то?? *фэйспалм* Из подвёрнутых штанов? Сидите уже в своём болоте и не гоните волну! Вот хорошо, что NoSQL появился - как только завёл про него речь - всё, увози д*#била!

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	29. "Релиз СУБД PostgreSQL 10"	–12 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 07:12
	>> Хорошая субд для тех кому скорость не нужна > Научись свой код оптимизировать. Ну соптимизируй мне join чтобы из 20 таблиц собирал аналог Mongo-вского документа хотя бы в 10 раз медленнее? А то пока что все 50 получается. Про JSONB/JSON не надо, функционала по сравнению с полноценной документной субд с гулькин гуль и при этом тормознее. Итого, "Хорошая субд для тех кому скорость не нужна" Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но зато уже хоть удобно что-то делать на ней. p.s. Да, я знаю usecase-ы где Слон быстрее Монги. Полнотекстовый поиск и "вытащить только пару полей из большого документа". Но жабовский полнотекстовый поиск ещё быстрее и продвинутее оказался, по второй проблеме - пока терпим. Как обойти тоже понятно. В остальном сплошнейшие плюсы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Релиз СУБД PostgreSQL 10"	+4 +/–
	Сообщение от Агроном (?), 06-Окт-17, 07:31
	Соптимизируй обновление этих 20 таблиц в монго, чтобы было устойчиво к сбоям и не оставляло БД в противоречивом состоянии, если что пошло не так. И чтобы это было хотябы в 10 раз медленее нормальной субд.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Релиз СУБД PostgreSQL 10"	–7 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 08:01
	>Соптимизируй обновление этих 20 таблиц в монго, Батя, не выставляй себя на посмешище, в Монго это будет одна таблица. Почитай про mongo data model, прежде чем комментировать. Какие проблемы с противоречивостью тебе померещились? В Монге все операции над документом атомарны, в том числе всякие прикольные навроде fineOneAndDelete или update с включенным upsert. А в РСУБД надо лепить транзакции и опять ТОРМОZZZzzzzzzzZZZZZа. Хотя, вы привыкшие, не замечаете :))))))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Агроном (?), 06-Окт-17, 08:59
	Имеется ввиду непротиворечивое обновление 20 документов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 09:07
	Для одаренных: В МОНГЕ ЭТО ОДИН ДОКУМЕНТ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Релиз СУБД PostgreSQL 10"	+3 +/–
	Сообщение от Аноним (-), 06-Окт-17, 13:01
	> Для одаренных: В МОНГЕ ЭТО ОДИН ДОКУМЕНТ. У тебя вся БД — один документ? Ну рад за тебя.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Релиз СУБД PostgreSQL 10"	+5 +/–
	Сообщение от evkogan (?), 06-Окт-17, 09:13
	Ни разу не пользовался монгой и решил посмотреть что же у них за data model такая волшебная. https://docs.mongodb.com/manual/core/data-model-design/ И тут оказывается, что их 2-е: Embedded Data Models и Normalized Data Models. Если под Ваши задачи Вам хватает Embedded Data Models и нужна скорость, то монго Ваш выбор. Но то что Вы даже не понимаете, что полно задач где нужна нормализация говорит только кто выставил себя на посмешище и ставит под сомнение остальные Ваши утверждения.
	Ответить \| Правка \| К родителю #36 \| Наверх \| Cообщить модератору


	47. "Релиз СУБД PostgreSQL 10"	–4 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 09:20
	>Вы даже не понимаете, что полно задач где нужна нормализация Не только эксперт по СУБД, сегодня впервые почитавший про mongo, ещё и Телепат? Я вот прекрасно понимаю где Монга не нужна и использую там другие решения. В отличие от местных фанатиков, которые лепят ВСЁ на РСУБД. При этом получая тормоза и MVCCшные глюки. Почитай как всё клёво с Слоне с репликацией и надежностью хранения: https://habrahabr.ru/company/southbridge/blog/322624/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от evkogan (?), 06-Окт-17, 09:53
	В отличие от местных фанатиков, которые лепят ВСЁ > на РСУБД. При этом получая тормоза и MVCCшные глюки. Фанатиком не являюсь, но считаю что для общих случаев, лучше подходит полноценная РСУБД. А применять все NoSQL надо там где нужно и не больше. Про надежность, ошибки бывают у всех. И то что есть их исправление в логах это хорошо. А то что в ченджлоге такого нет, не говорит о отсутствии ошибок. И да у нас все на Оракле все еще, но в свете импортозамещения по постгре посматриваем, пока издали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от evkogan (?), 06-Окт-17, 10:47
	> Почитай как всё клёво с Слоне с репликацией и надежностью хранения: > https://habrahabr.ru/company/southbridge/blog/322624/ почитал. Действительно интересно. Но прямо в этой версии добавили логическую репликацию. Может и по мотивам этой статьи. Так что дело движется. Хотя насколько я понимаю ни у Постгри, ни у Марии нормальной репликации нет. Есть разные поделки поверх. Каждая из которых под свою задачу. Что ж репликация бывает разной и возможно и правда нужны разные реализации, хотя лучше если они в официальной версии, а не поделка сверху. Тем не менее это не говорит, о том что везде надо применять NoSQL и в частности Монгу. То что в какой-то СУБД в каких-то версиях была ошибка приводящая к возможному повреждению данных при репликациях, не говорит о надежности NoSQL.
	Ответить \| Правка \| К родителю #47 \| Наверх \| Cообщить модератору


	58. "Релиз СУБД PostgreSQL 10"	–3 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 11:18
	> Тем не менее это не говорит, о том что везде надо применять NoSQL и в частности Монгу. Фраза была "ПГ хорошая, но тормозная СУБД". Кстати, с Оракле у меня опыта даже поболее, чем со Слоном. Производительность можно ещё в 1.5-2 раза делить :) а уж костыльность и замшелось просто бесконечны. Я бы лично хотел оказаться в будущем, где NOSQLей победят объектные СУБД. ObjectDB по описанию тортище. Но небесплатный... > То что в какой-то СУБД в каких-то версиях была ошибка приводящая к возможному повреждению данных при репликациях, не говорит о надежности NoSQL. Надежда умирает последней.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от кверти (ok), 06-Окт-17, 12:39
	На всю ту воду, что ты тут льешь, могу только посоветовать выровнять руки. Топором.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	118. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Led (ok), 11-Окт-17, 19:06
	> Надежда умирает последней. Хорошо, что ты не Надежда.
	Ответить \| Правка \| К родителю #58 \| Наверх \| Cообщить модератору


	44. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от _KUL (ok), 06-Окт-17, 09:09
	Используйте под задачи профильные средства их решения. Автомобили тоже хуже самолётов летают.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	49. "Релиз СУБД PostgreSQL 10"	+4 +/–
	Сообщение от Руби Род (?), 06-Окт-17, 09:57
	Nikolay Shestakov: Подход обозначенный Вами либо вытекает из вашего непрофессионализма, либо является простым троллингом. Так или иначе, расскажу свое мнение. 1. Несколько лет назад участвовал в разработке проекта со сложной логикой на стороне сервера приложения. База данных использовалась в качестве простого реляционного хранилища и взаимодействие с ней было реализовано через ORM Hibernate. Поддерживаемыми СУБД были MS SQL, Oracle и Postgres. Мы проводили нагрузочное тестирование на базе размером около 500Gb на не топовых серверах (памяти было толи 32Gb, то ли 64Gb. Точно не больше). Сервер приложений и СУБД находились на разных серверах. Нагрузка подавалась эмитацией работы реального пользователя через силениум (были несколько базовых сценариев работы пользователи и мы их полностью воспроизводили). Так вот: самой быстрой базой при нашем профиле использования оказалась MS SQL, а Oracle и Postgres были примерно одинаковыми (разрыв не превышал 10% от самой "быстрой" и самой "медленной" БД). 2. На текущем месте работы мы пытались использовать MongoDB в нескольких проектах. В одном из них размер базы около 250Gb (около 150M записей в одной таблице). База шардирована и реплицирована. При эксплуатации MongoDB такого объема возникла проблема с добавлением новых нод: на ребалансеровку шардов стало уходить до нескольких недель. В итоге конкретно в этом проекте от использования MongoDB отказались. При этом MongoDB продолжает использоваться в проектах где объем базы гораздо меньше. 3. Так получилось, что нам приходится для анализа хранить логи за последние 3 года (а в некоторых проектах и дольше). Ежедневный размер логов только сервиса в разработке которого принимаю участие я около 30Gb. Итого за три года 336530Gb ~ 32Tb. При этом по этим логам периодически считается всякая статистика. Ни postgresql ни MongoDB для этой задачи не подходят. Для хранения логов мы используем хранилище с возможностью выполнения Map/Reduce . Как можно догадаться, * в первом примере хорошо себя показывает Postgres, и совершенно не пригодны ни MongoDB, ни Map/Reduce; * во втором примере есть как удачный опыт использования MongoDB, так и неудачный; * в третьем не подходит ни MongoDB, ни Postgres. Так, что не надо говорить, что одна база лучше другой, а надо говорить, что в конкретно этой задаче база такая-то показала себя лучше чем база такая-то.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	50. "Релиз СУБД PostgreSQL 10"	–4 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 10:11
	1. В первом случае Монгу не тестили, хотя костыль под названием ORM это как раз попытки сделать из РСУБД Монгу (только очень тормозную). А можно просто взять быстрый Монго. 2. Про шарды ничего не скажу, хватает одного сервера с 1.3ТБ данных, ничего не тормозит. А репликация очень быстрая, за день с нуля синхронизируется на обычном эзернете. Случай три: map/reduce в Монго как раз есть. Итого, либо ДРЕВНЯЯ писулька про Монгу 2.х, либо ламер писал. В целом наблюдение: все рсудб уже давно в периоде стагнации, ничего путнего не добавляется, либо добавляется криво. Как например графы и json к слону, скорость как у черепахи Тортиллы. А носкли и в частности Монго развиваются семимильными шагами. Плюс, из-за более узкой специализации разрывают универсальные решения в виде рсубд.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Релиз СУБД PostgreSQL 10"	+3 +/–
	Сообщение от Руби Род (?), 06-Окт-17, 11:11
	Да, в первом случае MongoDB не тестили ибо тогда (2008 год) про такую СУБД еще никто не слышал. Не отрицаю, что я ламер в документо-ориентированных СУБД, это точно подмечено. Но зато у меня есть достаточно большой опыт в реляционных СУБД и некоторый опыт в Map/Reduce (и да, не на MongoDB). А вот на ORM Hibernate наезд был абсолютно зря: 1) Для документо-ориентированных СУБД тоже существуют свои ORM, например, OMG от тогоже Hibernate, а это значит, что с документо-ориентированными СУБД тоже есть класс задач, где проще отдать часть операции прослойке, а не делать самому. 2) Hibernate занимается вполне понятной задачей: отображает результат выполнения SQL запроса на объекты (и да, немного упрощает обновление данных и кеширование) 3) Избавляет от необходимости самому учитывать мелкие особенности каждой из поддерживаемой СУБД. И из последнего Вашего предложения вытекает, что узкоспециализированное решение MongoDB, хорошо подходит к задачам которые Вы решаете. А все ваши наблюдения про РСУБД - это ваши наблюдения в проекции решения ваших задач. В рамках задач решаемых мной, развитие РСУБД, в частности, postgres продолжается, и продолжается весьмы активно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Релиз СУБД PostgreSQL 10"	–3 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 11:39
	> И из последнего Вашего предложения вытекает, что узкоспециализированное решение MongoDB, > хорошо подходит к задачам которые Вы решаете. ...которые я решаю на Монго. А есть задачи которые я решаю НЕ на монго. И вообще, если уж связываться с РСУБД, то я всеми руками за ORM (можно было не распинаться). Изначальный тезис был: "Постгрес (и другие рсубд) тормоз". Его люто минусуют, но сказать в ответ нечего 8))))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Руби Род (?), 06-Окт-17, 11:47
	1) Вот твои слова "Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но зато уже хоть удобно что-то делать на ней." Из этой фразы вытекает, что пользоваться РСУБД без ORM неудобно. 2) РСУБД медленны при решении твоих задач, и надо тогда так и говорить, что в такой-то задаче РСУБД медленнее MongoDB, а не голословно утверждать, что РСУБД всегда медленнее MongoDB.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Релиз СУБД PostgreSQL 10"	–3 +/–
	Сообщение от лютый жабист__ (?), 06-Окт-17, 12:04
	>пользоваться РСУБД без ORM неудобно Современному программисту с ООП головного мозга - безусловно. 8) Некоторые ретрограды не признают ООП, не признают ОРМ, сидят себе пишут SQL-запросы от звонка до звонка. Скорость разработки ниже плинтуса.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от кверти (ok), 06-Окт-17, 12:44
	Современному погромисту с жабой головного мозга лучше вообще молчать. Молчать и слушать, что говорят.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от angra (ok), 06-Окт-17, 12:58
	> Скорость разработки ниже плинтуса. А скорость работы конечного продукта?
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	103. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ (?), 07-Окт-17, 17:16
	Ты из клованов орущих "ооп тормозит111". От правильного ооп прога только быстрее 8)))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от angra (ok), 08-Окт-17, 01:08
	Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10% на скорость и объем, а в ORM, который очень плохо ложится на SQL и либо заставляет тратить еще больше времени на оптимизацию по сравнению с написанием чистого SQL, либо спокойно может дать замедление на порядки в отдельных случаях.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	110. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ (?), 08-Окт-17, 11:33
	> Дело не в ООП, хотя оно тоже накладывает штрафы в районе 10% Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг Про орм - оно может и выигрыш давать, от рук зависит. Но монга как раз рулит там всё без сюрпризов - быстрее и орм и голого скуля в разы. Поэтому сейчас 50% проектов на носклях, 40% орм. 10% хипсторский скуль 8))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	112. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от angra (ok), 09-Окт-17, 12:32
	> Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг То есть ты пытаешься мне доказать, что ООП дает штраф не в 10%, а все 1000%. Ну окей, верю, что в жабке это так, но я говорил про ООП в нормальных языках. > Про орм - оно может и выигрыш давать, от рук зависит. Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL запросы, то ORM может иногда эту кривизну компенсировать.
	Ответить \| Правка \| К родителю #110 \| Наверх \| Cообщить модератору


	115. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ (?), 10-Окт-17, 07:21
	>> Сказки-с. В жабке Integer занимает 40-70 БАЙТ. Смотря какой режим, гггг > То есть ты пытаешься мне доказать, что ООП дает штраф не в > 10%, а все 1000%. Ну окей, верю, что в жабке это > так, но я говорил про ООП в нормальных языках. Это не отменяет того факта, что жабка номер один везде, кроме опеннета. 8)) >> Про орм - оно может и выигрыш давать, от рук зависит. > Само собой, если кривизна рук погромиста не позволяет ему писать нормальные SQL > запросы, то ORM может иногда эту кривизну компенсировать. Совершенно неправильно, ORM кривизну не компенсирует. Максимальный профит от ORM когда прогер знает SQL и ORM, но его избавляют от рутины.
	Ответить \| Правка \| К родителю #112 \| Наверх \| Cообщить модератору


	111. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ (?), 08-Окт-17, 13:34
	> ORM, очень плохо ложится на SQL Ты из престарелых ДБА? Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку. Соответственно, с самописным ДАО ничего не меняется, надо так же д вприсядку. А уж рефакторинг превращается в лютый гемор, в отличие от ОРМ. В итоге, правильный подход: девелопим продукт с ОРМ, потом если развитие ОСТАНОВЛЕНО (что почти никогда не бывает), можно выкинуть ОРМ. Но в прямых руках это не даст и нескольких процентов выигрыша. Соответственно, почти никто не делает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	113. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от angra (ok), 09-Окт-17, 12:45
	> Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку. Я тебе сейчас очень страшную вещь скажу, только ты присядь. ООП тоже очень плохо ложится на реальность. Листок бумаги с буковками не имеет методов, он не умеет сам ничего делать. И скрепленные или подшитые такие листочки, образующие документ, тоже не умеют сами по себе ничего делать, даже добавить новые листочки. Аналогично с папкой, в которой лежат документы и шкафом, где хранятся эти папки. Все они не умеют делать ровным счетом ничего. Это данные, но без методов. Вот такая вот суровая реальность. А вот схема работы реляционных БД, в которой есть СУБД(библиотекарь, секретарь) и собственно БД(шкафы, полки, папки, каталоги для индексации) почему-то очень реальность напоминает. Может потому, что с нее писалась.
	Ответить \| Правка \| К родителю #111 \| Наверх \| Cообщить модератору


	116. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ (?), 10-Окт-17, 07:26
	>> Неужели в 2017-м году ещё кто-то не в курсе, что это реляционная модель плохо ложится на реальность, а не ООП на реляционку. > Я тебе сейчас очень страшную вещь скажу Листок бумаги с буковками не имеет > методов, он не умеет сам ничего делать. Ну и глупость пишешь. Ты из тех "спецов" по ООП у которых прям настоящее наследование на struct-ах делается.
	Ответить \| Правка \| К родителю #113 \| Наверх \| Cообщить модератору