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

"Релиз СУБД PostgreSQL 10"	+/–
Сообщение от opennews (ok) on 05-Окт-17, 17:48
После года разработки доступна (https://www.postgresql.org/about/news/1786/) новая стабильная ветка СУБД PostgreSQL 10.  Обновления для новой ветки будут выходить (http://www.postgresql.org/support/versioning/) в течение пяти лет до октября 2022 года. Выбор номера версии 10 вместо 9.7.0 связано с переходом (http://www.databasesoup.com/2016/05/changing-postgresql-vers...) проекта на новую нумерацию выпусков. Вместо трёхуровневневой нумерации (Major1.Major2.Minor) отныне будет применяться  схема "Major.Minor", в которой "Major" указывает номер значительной ветки, а "Minor" - номер корректирующего обновления, не требующего перезаливки БД. Таким образом, первым корректирующим релизом PostgreSQL 10 станет 10.1, а следующей значительной версией  PostgreSQL 11. Как и раньше значительные версии будут формироваться раз в год. Основные новшества (https://wiki.postgresql.org/wiki/New_in_postgres_10): - Режим логической репликации (https://blog.2ndquadrant.com/logical-replication-postgresql-10/), позволяющий выборочно реплицировать только заданные таблицы или использовать репликацию в процессе обновления. Данный вид репликации манипулирует логическими изменениями на уровне выполняемых операций, в то время как традиционная репликация работает на очень низком уровне, перенося байтовые изменения в WAL-журнале; -  Добавлены встроенные возможности партицирования таблиц по диапазонам значений и спискам - разбивка теперь может задаваться (https://www.postgresql.org/docs/devel/static/ddl-partitionin...) через выражения "PARTITION BY" и "PARTITION OF" в директиве "CREATE TABLE". Например:    CREATE TABLE padre (      id             serial not null,      nombre         text not null,      fch_creado     timestamptz not null     )    PARTITION BY RANGE ( id );    CREATE TABLE hijo_0       partition of padre (id, primary key (id), unique (nombre))       for values from (unbounded) to (9);    CREATE TABLE hijo_1       partition of padre (id, primary key (id), unique (nombre))       for values from (10) to (unbounded); -  Обеспечено распараллеливание  с задействованием нескольких ядер CPU таких операций, как сканирование индексов и битовых карт, выполнение запросов со слиянием таблиц (JOIN); -  Возможность подтверждения коммитов на основе кворума для предотвращения потери данных после выхода из строя сразу нескольких синхронно реплицируемых узлов. Например, теперь можно указать, что коммит должен быть подтверждён любыми К из N запасных синхронно реплицируемых серверов, без жестко заданной последовательности проверки; -  Поддержка отслеживания (https://blog.2ndquadrant.com/traceable-commit-postgresql-10/) незавершённых коммитов - позволяет выяснить статус недавно запущенной транзакции для организации восстановления после краха или обрыва соединения; -  Поддержка аутентификации SCRAM-SHA-256 (https://ru.wikipedia.org/wiki/SCRAM) (вместо MD5) для организации более безопасного доступа по паролю; -  Многохостовый режим отказоустойчивости в libpq, при котором клиент соединяется с первым работающим хостом из заданного списка; -  Добавлен параметр "target_session_attrs", позволяющий клиенту запросить хост, доступный на запись или чтение; -  Для индексов типа Hash обеспечена поддержка репликации и повышена устойчивость к сбоям после крахов; -  Добавлен новый тип полномочий, определяющий доступ к функциям  мониторинга (pg_read_all_settings, pg_read_all_stats,     pg_stat_scan_tables и pg_monitor); -  Добавлено выражение XMLTABLE (https://blog.2ndquadrant.com/xmltable-intro/), позволяющее представить XML-документ в табличном формате, что существенно упрощает разбор XML-данных, хранимых в БД; -  Поддержка полнотекстового поиска для типов JSON и JSONB; -  Поддержка сжатия данных в журналах pg_receivewal (https://www.postgresql.org/docs/10/static/app-pgreceivewal.html); -  Добавлены средства для накопления статистики по корреляции данных в разных столбцах, которая может оказаться полезной для исключения выбора планировщиком некоторых ошибочных стратегий; -  Добавлена независимая от операционной системы реализация свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов. Реализация основана на libicu и идентична для Linux и Windows; -  Увеличена производительность функции SUM(), преобразования кодировок символов, выполнение выражений, группировки множеств и выполнения операций JOIN над уникальными столбцами. При выполнении аналитических запросов над большим числом строк наблюдается ускорение до 40%; -  Из нарушающих совместимость изменений отмечается переименование "xlog" в "wal", прекращение поддержки устаревшего протокола FE/BE 1.0, изменение настроек по умолчанию для репликации и резервирования (pg_basebackup), прекращение поддержки значений времени (Timestamps) с плавающей запятой, удаление  contrib/tsearch2  и прекращение поддержки в pg_dump баз данных от  PostgreSQL 7.4  и более ранних выпусков. URL: https://www.postgresql.org/about/news/1786/ Новость: http://www.opennet.dev/opennews/art.shtml?num=47337
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Релиз СУБД PostgreSQL 10"	–10 +/–
Сообщение от Iaaa (ok) on 05-Окт-17, 17:48
Вот и до этих мода на симуляцию развития рисованием красивых цифр дошла (
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Релиз СУБД PostgreSQL 10"	+30 +/–
	Сообщение от h31 (ok) on 05-Окт-17, 17:54
	Ребята дело делают. Пофиг на циферки.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Релиз СУБД PostgreSQL 10"	+18 +/–
	Сообщение от KonstantinB (ok) on 05-Окт-17, 18:40
	Наоборот, сменили нумерацию на более логичную. Бинарная несовместимость данных между версиями X.Y и X.Y+1 выглядит странно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от фывфыв on 05-Окт-17, 22:05
	Ага, а потом опять дойдут до версий 50 и решат что слишком много и вернуться обратно. Не они первые, не они последние.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	20. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Аноним (??) on 06-Окт-17, 00:32
	less и systemd возвращаться не собираются
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	45. "Релиз СУБД PostgreSQL 10"	+7 +/–
	Сообщение от Аноним (??) on 06-Окт-17, 09:10
	Правильно, вот и пусть systemd идёт как можно дальше в less :)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	81. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 06-Окт-17, 12:58
	Эй, вот не надо хотя бы в less свой системде пихать! А то чем файлы-то смотреть? Придётся ж more из фряхи портировать.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	30. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от 1222 on 06-Окт-17, 07:25
	С таким циклом разработки Postgre SQL 50 выйдет в 2057 году... Дожить бы до этого.....
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

4. "Релиз СУБД PostgreSQL 10"	+1 +/–
Сообщение от Аноним (??) on 05-Окт-17, 17:56
офиц. пресс-релиз на русском  https://www.postgresql.org/about/press/presskit10/ru/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Релиз СУБД PostgreSQL 10"	–45 +/–
Сообщение от лютый жабист__ on 05-Окт-17, 18:33
Хорошая субд для тех кому скорость не нужна
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Релиз СУБД PostgreSQL 10"	+11 +/–
	Сообщение от KonstantinB (ok) on 05-Окт-17, 18:42
	> Хорошая субд для тех кому скорость не нужна "Сильное заявление, проверять его я, конечно, не буду" (c) Говорить о скорости можно только в контексте определенных юзкейсов и совместно с иными требованиями, такими как гарантия целостности. Так-то записать данные в /dev/null быстрее всего.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	101. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Maxim Filatov on 07-Окт-17, 11:08
	Is /dev/null webscale?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	102. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Andrey Mitrofanov on 07-Окт-17, 11:13
	> Is /dev/null webscale? No, it's super-trans-hyper-pooper-webscale!
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	119. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 12-Окт-17, 03:40
	> No, it's super-trans-hyper-pooper-webscale! Pooper это профессия от слова poop?
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	120. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Andrey Mitrofanov on 12-Окт-17, 09:52
	>> No, it's super-trans-hyper-pooper-webscale! > Pooper это профессия от слова poop? Словарь не тут.   ---Ж*** есть, а слова нету.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	8. "Релиз СУБД PostgreSQL 10"	+4 +/–
	Сообщение от andy (??) on 05-Окт-17, 19:04
	> Хорошая субд для тех кому скорость не нужна Научись свой код оптимизировать.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	104. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от SunXE (ok) on 07-Окт-17, 17:48
	У нас шардинг кластер монги на 1.3Тб. Действительно, если канал между серверами слабый, то синкнуть реплеку простым добавленим сервера очень долго, так что оплог может закончится. Лучшим способом является залочить одну из реплек на запись и тупо скопировать файлы rsync-м с сжатием при копировании. Но это всё максимум сутки, несколько недель это какая-то фантастическая цифра. Никакого оплога на такое не хватит, звучит как то что вы придумали эту цифру.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	65. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Вася (??) on 06-Окт-17, 11:51
	Положи свой документ в колонку BSON и живи спокойно.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	68. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 12:06
	>Положи свой документ в колонку BSON и живи спокойно. Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги на 1меговых объектах. На маленьких не тестил, но полагаю, что ничего похожего на 100к/сек не будет. Про неудобство работы молчу. Местами монговский контейнер BSON даже удобнее родных объектов. Слон НИЧЕГО подобного не предлагает.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	83. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от anonymous (??) on 06-Окт-17, 13:01
	>>Положи свой документ в колонку BSON и живи спокойно. > Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги > на 1меговых объектах. > На маленьких не тестил, но полагаю, что ничего похожего на 100к/сек не > будет. > Про неудобство работы молчу. Местами монговский контейнер BSON даже удобнее родных объектов. > Слон НИЧЕГО подобного не предлагает. Просто неасилятор и профан в postgres, а так же фигляр и позёр по жизни. Вот и весь разговор.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	85. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 06-Окт-17, 13:44
	>[оверквотинг удален] > 50 получается. > Про JSONB/JSON не надо, функционала по сравнению с полноценной документной субд с > гулькин гуль и при этом тормознее. > Итого, "Хорошая субд для тех кому скорость не нужна" > Приделываю ORM, скорость из под плинтуса переползает вообще на предыдущий этаж, но > зато уже хоть удобно что-то делать на ней. > p.s. Да, я знаю usecase-ы где Слон быстрее Монги. Полнотекстовый поиск и > "вытащить только пару полей из большого документа". Но жабовский полнотекстовый поиск > ещё быстрее и продвинутее оказался, по второй проблеме - пока терпим. > Как обойти тоже понятно. В остальном сплошнейшие плюсы. Чего-чего ?! :-D они там в монге своей добавили хотя бы валидацию json при добавлении документов ? или до сих пор вставляй что угодно, а потом map/reduce валится (ни о каких зачатках ACID речи ясное дело не идет)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	88. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 16:21
	> Чего-чего ?! :-D они там в монге своей добавили хотя бы валидацию > json при добавлении документов ? или до сих пор вставляй что > угодно, а потом map/reduce валится (ни о каких зачатках ACID речи > ясное дело не идет) давай сюда пример инвалидного json, который съест монга 3.4 или 3.2, а то сам знаешь кто.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	90. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от KonstantinB (ok) on 06-Окт-17, 19:21
	"Жабист" в нике объясняет такое мнение. :-) Если рассматривать СУБД чисто как слой персистенции, и вся работа с оной сводится к fooRepository.find(id) и fooRepository.store(entity) - тогда, конечно, РСУБД не только не нужна, но и мешает из-за impedance mismatch. Тут, конечно, любое документное хранилище подойдет лучше. Но это вообще не та задача, для которой РСУБД задумывались.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	107. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от Kodir (ok) on 08-Окт-17, 00:56
	> ...Mongo-вского документа Хоспыдя... хипстеры, откуда вы лезете-то?? *фэйспалм* Из подвёрнутых штанов? Сидите уже в своём болоте и не гоните волну! Вот хорошо, что NoSQL появился - как только завёл про него речь - всё, увози д*#била!
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	9. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Отражение луны (ok) on 05-Окт-17, 19:16
	Хорошая БД для тех, кому нужна надежность. Ну а для сайтиков есть все остальное, пользуйтесь.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	17. "Релиз СУБД PostgreSQL 10"	–4 +/–
	Сообщение от KroTozeR (ok) on 05-Окт-17, 21:36
	> Хорошая БД для тех, кому нужна надежность. Ну а для сайтиков есть > все остальное, пользуйтесь. И, вместе с тем, это — БД, которой никогда не было удобно пользоваться.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	28. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 07:05
	>Хорошая БД для тех, кому нужна надежность. Ну-ну. На моей памяти совсем недавно проскакивали багфиксы в духе "ой, мы при некоторых обстоятельствах теряли данные, ну вы эта, обновитесь". Причём не раз. https://habrahabr.ru/company/southbridge/blog/322624/
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	93. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от Аноним (??) on 06-Окт-17, 20:27
	Это ты так бесишься потому что все с java на go переходят, а в go ты ничего не смыслишь и никому не нужен, да?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	117. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от Павел (??) on 10-Окт-17, 21:19
	На go? Люто проиграл с этого. Казалось, что на go переходят только php и python программисты. А теперь я узнал, что и джависты, которые не смогли осилить скалу.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	96. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 06-Окт-17, 20:36
	А MongoDB вообще не работала. > new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	100. "Релиз СУБД PostgreSQL 10"	–3 +/–
	Сообщение от лютый жабист__ on 07-Окт-17, 10:11
	> А MongoDB вообще не работала. >> new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4 Ты правда такой или прикидываешься? Джепсены тестят момент переключения мастер-слейв. Подавляющее большинство субд его ФЭЙЛЯТ. И монга УЖЕ не фэйлит, а ваш слон стыдливо не заказывает тест. В пг вообще есть репликация-то? Судя по комментам какие-то внешние костыли. Так что не позорься уж
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	108. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 08-Окт-17, 01:04
	А сам ты правда такой или прикидываешься? MongoDB фейлила, причём не раз и продолжит фейлить, потому что ошибки есть во всех программах.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	10. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от rshadow (ok) on 05-Окт-17, 19:19
	LOL
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Релиз СУБД PostgreSQL 10"	+12 +/–
	Сообщение от Michael Shigorin (ok) on 05-Окт-17, 19:49
	> Хорошая субд для тех кому скорость не нужна >> жабист
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	13. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 05-Окт-17, 20:53
	Зависит от объема данных. Или вам больше по душе снежный ком MySQL?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Релиз СУБД PostgreSQL 10"	–6 +/–
	Сообщение от ACCA (ok) on 05-Окт-17, 21:06
	> Зависит от объема данных. Или вам больше по душе снежный ком MySQL? Нет, не зависит. Full table scan, 30 млрд. записей, 600-800 мсек. Нужно только думать головой.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	24. "Релиз СУБД PostgreSQL 10"	+4 +/–
	Сообщение от angra (ok) on 06-Окт-17, 02:15
	Если запись длиной хотя бы в 70 байт, то это три терабайта в секунду, что на четыре порядка превосходит максимальную скорость чтения ssd. То есть только для того, чтобы сделать проход по данным, нужно параллельное чтение с 10k ssd. Ну давай расскажи, как это преодолевается теми, кто думает головой.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	52. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Мимо проходил on 06-Окт-17, 10:24
	Может он на ram disk какой выгружает это барахло предварительно? Но durability будет шикарная, да.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	69. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Аноним (??) on 06-Окт-17, 12:08
	3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, что прочитанные данные надо ещё как-то обработать.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	92. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от ыы on 06-Окт-17, 19:46
	> 3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, что > прочитанные данные надо ещё как-то обработать. Шардинг же... таблица раскидана на 100 серверов...
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	121. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от ACCA (ok) on 12-Окт-17, 16:42
	>> 3 ТБ/с даже для оперативки овердохрена, не говоря уж о том, что Об этом и речь - головой нужно думать, если у тебя есть нормальный инструмент. > Шардинг же... таблица раскидана на 100 серверов... index-only scan по одному измерению + partitioning по другому. Посмотрел на результаты - шардинг оказался даже не нужен.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	27. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от iPony on 06-Окт-17, 05:05
	Близко. Оракл же.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	14. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от ACCA (ok) on 05-Окт-17, 21:04
	"Скорость" ты сравнивал по select count(*), полагаю? И не учитывал спец. сборки вроде Postgres XL, Netezza или GreenPlum.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	19. "Релиз СУБД PostgreSQL 10"	+3 +/–
	Сообщение от Andrey Mitrofanov on 05-Окт-17, 22:38
	> "Скорость" ты сравнивал по select count(*), полагаю? Это известный эксперт по замерам. Его линейка длинее!!! У него даже grep тормозит.  grep -F 'Карл!' > И не учитывал спец. сборки вроде Postgres XL, Netezza или GreenPlum. Ах! Оставьте.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	74. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Andrey Mitrofanov on 06-Окт-17, 12:23
	>> "Скорость" ты сравнивал по select count(*), полагаю? > Это известный эксперт по замерам. > Его линейка длинее!!! > У него даже grep тормозит.  grep -F 'Карл!' Чорд! У него опять обострилось сравнения тёплого с мягким по дюймовой линейке, в #68 выше: "Я тестил, у Постгреса скорость раз в 10 ниже, чем у Монги на 1меговых объектах." #разувидеть   ..."на моих задачах" читать "на моём радиусе кривизны" > Ах! Оставьте.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от YetAnotherOnanym (ok) on 06-Окт-17, 00:51
	XL или XC? А то Коичи там кучу проектов нафоркал, который настоящий - без поллитры не разберёшь.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	26. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от Гнилой Бутират и его Поле чудес on 06-Окт-17, 03:06
	> XL или XC? А то Коичи там кучу проектов нафоркал, который настоящий > - без поллитры не разберёшь. Форка на форке, а в итоге толку ноль все сами себе буратины.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	37. "Релиз СУБД PostgreSQL 10"	–4 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 08:07
	> "Скорость" ты сравнивал по select count(*), полагаю? > И не учитывал спец. сборки вроде Postgres XL, Netezza или GreenPlum. Моя основная рабочая база 1.3ТБ всего, монга прекрасно тянет и на одном сервере, зачем мне ваши Postgres XL, ещё и не бесплатные наверно? Объекты примерно в 1мегабайт. Из другого проекта - объекты маленькие до килобайта, итого гигов 100 всего. Но по структуре штук 20 разных типов с разными полями. У монги скорость загрузки 100к в сек, отдача 1-2мс. Из третьего проекта - объекты в районе 1кб, поля все одинаковые (но иерархические само собой) . Надо было отсекать дубли, создал unique index, монга после 200млн записей стала тормозить на вставку до 200зап/сек. Сервер с 16ГБ ОЗУ, больше нет. Думаю, ну всё, Монга, прощай. Начал переносить в Слона, а он сдулся намного раньше. А уж mass update одного поля в базе 200млн записей это просто смерть всему и вся. Привет ACID. В Монге вообще не влияет на скорость работы. В целом, ACID нужен "почти никогда", а тормозит он "мама не горюй". Щас понабегут банкиры, у всех транзакции в слоне и миллиарды ворочаются.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	39. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от 1222 on 06-Окт-17, 08:57
	Не корректно сравнивать SQL и noSQL СУБД. Всё таки всё зависит от контекста использования. Можно микроскопом гвозди забивать, а можно и ломом коктейли мешать.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	70. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 06-Окт-17, 12:10
	> можно и ломом коктейли мешать Ртутные коктейли урановым ломом?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	76. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от Аноним (??) on 06-Окт-17, 12:26
	>> можно и ломом коктейли мешать > Ртутные коктейли урановым ломом? Железные же, всплывают!
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	51. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Бронтозавр on 06-Окт-17, 10:13
	Мне вот просто интересно, откуда у вас такие базы по терабайту? Что вы в них храните, результаты экспериментов на БАКе? У GitLab размер базы около 310 гигов был на момент сбоя в январе. По GitHub информацию не нашел, но данные GitHubArchive за 2016 год весят 766 гигов ( https://bigquery.cloud.google.com/table/githubarchive:year.2... ).
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	57. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 11:12
	> Мне вот просто интересно, откуда у вас такие базы по терабайту? Что > вы в них храните, результаты экспериментов на БАКе? Уровень экспертов опеннета налицо? 20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы. А БАКом генерят сотни терабайт в год. Не вижу смысла расписывать, что в этих 1.3ТБ.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	64. "минутка статистики и рекламы орацледб"	+1 +/–
	Сообщение от Andrey Mitrofanov on 06-Окт-17, 11:50
	>> Мне вот просто интересно, откуда у вас такие базы по терабайту? Что >> вы в них храните, результаты экспериментов на БАКе? > Уровень экспертов опеннета налицо? 20-50ТБ это объём ERP-базки не самой большой по > меркам планеты конторы. А БАКом генерят сотни терабайт в год. '2007: "15 PetaBytes of new data each year stored" http://www-conf.slac.stanford.edu/xldb07/xldb_lhc.pdf   <= https://duckduckgo.com/?q=LHC+CERN+database&t=ffab&ia=web "Since 2001 - RDBMS + files Idea of consistent storage of all data in databases was dropped Hybrid model    • Bulk data in files (largely read-only)    • Only key meta-data in RDBMS" "110 server nodes - RHEL 5, Oracle 10g" "Tomorrow    - Petabyte flash-RAM and in-memory databases?" + '2008 http://www-conf.slac.stanford.edu/xldb08/slides/xldb2_cern_g... + '2009 http://openlab.cern/sites/openlab.web.cern.ch/files/presenta... '2012 https://duckduckgo.com/?q=LHC+CERN+mongo ? В 2012-ом какую-то "мелочь" в mongo сложили. http://www.techrepublic.com/blog/european-technology/cern-wh.../ : ..."will generate some 22PB of data this year, and that's after throwing away 99 per cent of what is recorded by the LHC detectors." '2017: http://www.techrepublic.com/article/cern-we-generate-1pb-eac.../ "Cern: 'We generate 1PB each second." "While the bulk of this data is thrown away"...  //сколько пишут не сказали, вроде. > Не вижу смысла расписывать, что в этих 1.3ТБ.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	91. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от ыы on 06-Окт-17, 19:34
	>Уровень экспертов опеннета налицо? >20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы. Вы бы не могли назвать эту контору? а так же каким образом были получены вами сведения о размере упомянутой базы? >Не вижу смысла расписывать, что в этих 1.3ТБ. В зависимости от ответа выше - будет комментарий и сюда.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	99. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от лютый жабист__ on 07-Окт-17, 10:06
	>>20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы. > Вы бы не могли назвать эту контору? а так же каким образом > были получены вами сведения о размере упомянутой базы? Мусохранск-нефтегаз. Знаю, сколько стораджа сапёрам дали. Уже больше 20, хотя да, наверняка там 19.5тб архив порнухи занимает, а сама база 500. Ведь не бывает баз больше пресвятого гитхаба. Ггг
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	106. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от ыы on 07-Окт-17, 19:33
	>>>20-50ТБ это объём ERP-базки не самой большой по меркам планеты конторы. >> Вы бы не могли назвать эту контору? а так же каким образом >> были получены вами сведения о размере упомянутой базы? > Мусохранск-нефтегаз. Знаю, сколько стораджа сапёрам дали. Уже больше 20, хотя да, наверняка > там 19.5тб архив порнухи занимает, а сама база 500. Ведь не > бывает баз больше пресвятого гитхаба. Ггг И откуда такая уверенность что на этом сторадже лежит именно ERP база?
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	59. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от Да аноним on 06-Окт-17, 11:39
	Надо понимать, что если в базе хранится что-нибудь специфическое, то что именно - это NDA (информация для служебного пользования) Про БАК и как они хранят данный можно послушать где-то здесь https://events.yandex.ru/events/ds/17-sept-2016/ (Очень кратко: 99,9% данных сразу удаляется и не хранится) А если общими словами, то что такое 1TB: 1) 700 полнометражных фильмов (в низком качестве) 2) 500K музыкальных произведений (в низком качестве) 3) Логи за 1 месяц среднего (или даже небольшого) сервиса Ну и много еще чего
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	71. "Релиз СУБД PostgreSQL 10"	+1 +/–
	Сообщение от Andrey Mitrofanov on 06-Окт-17, 12:13
	> А если общими словами, то что такое 1TB: > 1) 700 полнометражных > 2) 500K музыкальных > 3) Логи за 1 месяц среднего 15 PetaBytes => "CD stack with 1 year LHC data! (~ 20 Km)"   --стр.14 http://openlab.cern/sites/openlab.web.cern.ch/files/presenta... +++"А во флоппы-дисках я значииительно длинееее."
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	34. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от Агроном on 06-Окт-17, 07:43
	>Хорошая субд для тех кому скорость не нужна Старый (очень) анекдот на эту тему. Спорят 2 программиста:   - Уменя программа работает быстрее твоей в 10 раз   - Зато моя работает правильно, а твоя нет
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	38. "Релиз СУБД PostgreSQL 10"	–3 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 08:21
	>Зато моя работает правильно, а твоя нет Самый смех в том, что Pg не только медленнее, ещё и работает неправильно. Я что-то в changelog Монги не помню ничего про потерю данных. А в Pg было и не раз. Кстати, как там в правильном Pg с репликацией, полноценный master-slave есть, само переключает? Ни одна acknowledged запись гарантированно не теряется? Или может master-master уже из коробки появился?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	41. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 09:03
	Интересное чтиво: https://habrahabr.ru/company/southbridge/blog/322624/ Из эпичного: логически небольшое обновление (скажем, запись нескольких байт) становится гораздо более серьезной и ресурсоемкой операцией на физическом уровне. После того как мы обновили год рождения al-Khwārizmī, не изменились ни первичный ключ записи, ни значения имени и фамилии. И все же индексы приходится обновлять, поскольку в базе данных появился новый кортеж. Для таблиц с большим количеством вторичных индексов эти дополнительные шаги могут приводить к значительным накладным расходам на запись. Например, для таблицы с десятком индексов обновление поля, покрытого лишь одним индексом, должно быть распространено на остальные девять, поскольку необходимо прописать в них ctid новой строки. Проблема с усилением записи затрагивает и репликацию, которая выполняется на уровне представления данных на диске. Вместо передачи небольшой логической записи, такой как, например, «Изменить год рождения для ctid D, установив его в 770», СУБД должна переслать все элементы WAL, касающиеся четырех вышеупомянутых операций, сопровождающих запись. Таким образом, проблема усиления записи переходит в проблему усиления репликации, и поток репликационных данных Postgres очень быстро становится настолько значительным, что может занять большую часть доступной пропускной способности сети. Во время стандартной операции по увеличению емкости базы данных, при которой использовался механизм повышения роли реплики, мы столкнулись с ошибкой в Postgres 9.2. Реплики некорректно обрабатывали переключение шкалы времени (timeline switch), в результате чего некоторые из них неверно применяли обновления WAL. Из-за этой ошибки некоторые записи, которые должны были быть деактивированы механизмом версионирования, не получили соответствующую пометку, то есть остались активны. поскольку ошибка проявлялась на всех серверах, каждый из них портил разные строки, то есть на одной реплике строка X могла быть повреждена, а Y нетронута, но на другой реплике строка X могла быть в порядке, а Y — повреждена. На самом деле мы точно не знали, на скольких репликах были поврежденные данные, а также проявлялась ли эта проблема на мастере.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	53. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от Мимо проходил on 06-Окт-17, 10:30
	Переключалка через pacemaker отлично работает.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	55. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от лютый жабист__ on 06-Окт-17, 11:06
	А без Shared Storage? А то так можно сказать что репликацию поддерживает и SQLite.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	79. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от anonymous (??) on 06-Окт-17, 12:47
	https://www.youtube.com/watch?v=SNzOZKvFZ68
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	84. "Релиз СУБД PostgreSQL 10"	+2 +/–
	Сообщение от OhBoyHereWeGo on 06-Окт-17, 13:18
	https://jira.mongodb.org/browse/SERVER-2237?jql=issuetype�...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	87. "Релиз СУБД PostgreSQL 10"	–2 +/–
	Сообщение от лютый жабист__ on 06-Окт-17, 16:18
	> https://jira.mongodb.org/browse/SERVER-2237?jql=issuetype�... Huge data loss after altering files in dbpath on a running instance Это баг в мозге у одмина, зарепортившего такое. Давай уже не багтрекер, а реальный changelog с data loss. Ещё половина багов в репликации, что уже привели в идеал в 3.4, а в Слоне до сих пор ОТСУТСТВУЕТ вообще.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	94. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 06-Окт-17, 20:33
	https://aphyr.com/posts/322-jepsen-mongodb-stale-reads
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	95. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Аноним (??) on 06-Окт-17, 20:34
	In this Jepsen analysis, we develop new tests which show the MongoDB v0 replication protocol is intrinsically unsafe, allowing the loss of majority-committed documents. In addition, we show that the new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4. While the v0 protocol remains broken, patches for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite. This work was funded by MongoDB, and conducted in accordance with the Jepsen ethics policy.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	105. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от SunXE (ok) on 07-Окт-17, 18:03
	Да, с версии v3.4 наконец перестали самопроизвольно реплики вылетать в unrecoverable. До того, 2-3 раза в месяц приходилось перезаливать реплику из соседней.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	66. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от лютей лютого жабиста__ on 06-Окт-17, 11:56
	Расскажи нам опять, что монга круче справиться ;)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

12. "Релиз СУБД PostgreSQL 10"	+2 +/–
Сообщение от Catwoolfii (ok) on 05-Окт-17, 20:19
Презентация к релизу https://postgrespro.ru/media/2017/10/05/postgres-10-hse-2017...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Релиз СУБД PostgreSQL 10"	–2 +/–
Сообщение от Casm (??) on 05-Окт-17, 21:12
На сайте пока не даёт выбрать 10 для загрузки. Для Centos 7 можно установить так: 1. Устанавливаем PostgreSQL 10.X Yum Repository Configuration rpm -i https://download.postgresql.org/pub/repos/yum/10/redhat/rhel... 2. Устанавливаем сервер через yum: yum install postgresql10-contrib.x86_64 postgresql10-server.x86_64
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Релиз СУБД PostgreSQL 10"	–1 +/–
Сообщение от DRM on 06-Окт-17, 00:41
ClickHouse, RocksDB быстрее PgSQL дрянных хранилок
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от KonstantinB (ok) on 06-Окт-17, 02:06
	ClickHouse - колоночная база. RocksDB - встраиваемая библиотека для key-value. Что значит "быстрее"-то? - Грузины лучше, чем армяне! - Чем? - Чем армяне!
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	25. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от DRM on 06-Окт-17, 02:55
	Thread pool из коробки тоже нету
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Агроном on 06-Окт-17, 07:39
	>ClickHouse - колоночная база. Это где таблицы с инверсным хранением? Можно подобрать случаи, когда такой подход лучше, но в общем случае, в нормальной субд, мы находим запись с нужным значением поля и тут же все остальные поля нам доступны в памяти, потому что хранятся вместе. В инверсной бд для каждого значения нужно еще прогуляться , чтобы получить значение, что, понятно, будет медленее.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	31. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Вареник on 06-Окт-17, 07:27
	Таких имен тысячи. Узкоспециализированных продуктов под какой-то тип данных и тип хранения.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	42. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Да аноним on 06-Окт-17, 09:04
	ClickHouse разве не append-only?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	63. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от PnD (??) on 06-Окт-17, 11:47
	Он ещё и не совсем ACID. Зато заточен под стат. расчёты по очень-очень "плотно" вливаемым данным. Возможно, ещё складывать некоторые логи подойдёт. Лично я к нему с интересом приглядываюсь (пока).
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

61. "Релиз СУБД PostgreSQL 10"	–2 +/–
Сообщение от Abu on 06-Окт-17, 11:46
= Декларативное партиционирование таблиц: разделяйте ваши данные с лёгкостью = Эх! Глядишь и на Zabbix'e жить станет попроще.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	72. "Релиз СУБД PostgreSQL 10"	+/–
	Сообщение от Andrey Mitrofanov on 06-Окт-17, 12:16
	> = > Декларативное партиционирование таблиц: разделяйте ваши данные с лёгкостью > = > Эх! Глядишь и на Zabbix'e жить станет попроще. Тише-тише, не так скоро! Сначала с 8.3 надо слезьть.   //ну, с 9.1, ладно
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	97. "Релиз СУБД PostgreSQL 10"	–1 +/–
	Сообщение от abu on 07-Окт-17, 04:41
	все равно - чую приближение весны (:
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

89. "Релиз СУБД PostgreSQL 10"	–2 +/–
Сообщение от Штунц on 06-Окт-17, 17:28
> В модуле file_fdw появилась возможность запуска внешних программ, например, можно импортировать данные в таблицу из сжатого файла, запустив gunzip для распаковки и использовать pgAdmin в качестве эмулятора терминала
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

98. "Лютому жабисту посвящается"	+/–
Сообщение от Аноним (??) on 07-Окт-17, 09:30
https://www.youtube.com/watch?v=b2F-DItXtZs
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

114. "Релиз СУБД PostgreSQL 10"	–3 +/–
Сообщение от Аноним (??) on 09-Окт-17, 15:19
"Комитом" унитазы моют. А БД -- транзакции ФИКСИРУЮТ.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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