Компания Percona объявила о выходе Percona Server для MongoDB 3.4, Percona Monitoring and Management 1.1 и Percona Toolkit 3.0

А это когда-нибудь одобрят?

Нет.

Тогда удалите, чего висит за зря?

Почти месяц висит. Непорядок...

Ура, свершилось!

Зачем оно надо, если есть Arangodb?

Вот не хочу никого обидеть. Но вот читать такое на техническом ресурсе:

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

А могут быть не использованы. Или можно их использовать вместе без достижения оптимальной производительности? В этой фразе какой смысл?

Или вот:

Интегрированная подключаемая аутентификация через LDAP позволяет создать централизованный сервис аутентификации для предприятия.

Черт побери. http://cdn.simba.com/products/MongoDB/doc/JDBC_InstallGuide/content/jdbc/mo/a...

И вот куда не ткни «на основе RocksDB, разработан специально для значительных рабочих нагрузок». Я сейчас даже напишу Кевину Райану это какого... они старый движок разрабатывали СПЕЦИАЛЬНО для малых рабочих нагрузок. И почему значительные рабочие нагрузки в RocksEngine Обеспечивают максимальные задержки.

Лучшеб и не одобряли.

Зачем оно надо если есть PostgreSQL превосходящее хипстерские поделки даже на задачах которые казалось бы созданы именно для них?

Зачем оно надо если есть PostgreSQL превосходящее хипстерские поделки даже на задачах которые казалось бы созданы именно для них?

Доооо, превосходит:

https://www.arangodb.com/wp-content/uploads/2015/09/table_v2071.png

И что мы видим на этой картинке:

single read, single write - для Postgresql json в пределах погрешностей, следущий за ними single write sync на четверть быстрее. neigbors with profile data на треть быстрее. Память расходуется на 15% экономней. Значительное отставание на каких то специфических алгоритмах для которых проще написать плагин нечем создавать велосипед. Не понимаю к чему эта картинка.

Бомбануло и начал высасывать оправдания из пальца?

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

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

Я впервые слышу такие страшные слова, понял примерно 2% из всего сказанного поэтому к сожалению не смогу ответить на ваш вопрос.

Ты вообще в постгресе разбираешься, или так, название запомнил? =)

мастер-мастер есть в Postgres-bdr - но он какой то костыльный все равно, для прода не рискнули ...

dba@localhost с 3 табличками детектед

Абсолютно всё о постгресе конечно не знаю, только то что было надо узнать что бы переписать хипстерский nosql проект от которого загибался 8-ядерный opteron c 32 гигами памяти и SSD.

Обычно грамотные люди с SQL на NoSQL в крупных проектах уходят. Для того чтобы производительность и стабильность увеличить.

Но судя по твоим постам, ты переписал свой же хипстерский NoSQL проект уровная палка-палка-огуречик, на SQL того же уровня

Обычно грамотные люди с SQL на NoSQL в крупных проектах уходят. Для того чтобы производительность и стабильность увеличить.

NoSQL <...> стабильность увеличить.

lol.

Стабильность и nosql это диаметрально противоположные понятия. Какого увеличения стабильности можно ожидать при отказе от строгой организации данных. В nosql'ах как правило даже транзакции не поддерживаются либо урезаны. Ты подожди немного и твоя база данных превратится в болото с говном в котором с каждым разом будет всё труднее разобраться.

А че ты смеешься?

Стабильность и nosql это диаметрально противоположные понятия.

Обоснуй =)

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

Это к стабильности вообще никаким боком не относится. «Стабильность» - это когда твоя постгрескуэль на локалхосте падает и прощай данные.

В nosql'ах как правило даже транзакции не поддерживаются либо урезаны.

Не урезаны, а не предусмотрены. И это, зная как работает конкретное NoSQL решение - не проблема.

Ты подожди немного и твоя база данных превратится в болото с говном в котором с каждым разом будет всё труднее разобраться.

А здесь мы плавно переходим из темы хранения данных в архитектуру приложения. Если твоя архитектура говно - то твой любимый SQL тем более не поможет =)

«Стабильность» - это когда твоя постгрескуэль на локалхосте падает и прощай данные.

Моя Postgresql ни разу не падала и как раз таки работает стабильно на 100%, а вот твоя mongodb ещё как падала а когда её запускаешь после краша эта тварь вроде как уже запустилась а соединения не принимает довольно долго после этого а однажды и вовсе не запустилась, админ восстанавливал всё из бэкапа.

Не урезаны, а не предусмотрены. И это, зная как работает конкретное NoSQL решение - не проблема.

Конечно не проблема если пихать многослойные данные в один документ без нормализации. В итоге база данных которая в Postgresql 10 G разрослась до 200 G, многие страницы загружались по 10 минут а с Postgresql моментально на тех же данных.

А здесь мы плавно переходим из темы хранения данных в архитектуру приложения. Если твоя архитектура говно - то твой любимый SQL тем более не поможет =)

Ещё как поможет: foreign keys, triggers, constraint checks всё это не допустит помещение некорректных данных: даже если код приложение говно Postgresql просто выдаст ошибку и отменит транзакцию не допустив нарушения логической целостности данных в базе.

А че ты смеешься?

То, что в NoSQL базах обычно нет поддержки ACID и если произойдут проблемы с самой БД (выключится электричество, баги в ПО и пр), то - «привет». Поэтому для «бложиков»-«каталожиков» NoSQL может и подойдет, а вот финансовые транзакции - «ни в коем случае».

На кой она в бложиках-каталожиках если проще и эффективнее подойдёт PostgreSQL. Единственное на что годится nosql - для проведения тестов производительности в сферическом вакууме где она на каких специфических запросах обгоняет по производительности.

если произойдут проблемы с самой БД (выключится электричество, баги в ПО и пр)

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

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

Суть в одном - SQL рулит где достаточно расширяться вертикально до какого-то ограниченного предела. NoSQL для того, чтобы расширяться горизонтально. И таких задач гораздо больше в настоящее время и простыми бложиками не ограничивается, для бложиков и какого-нибудь SQLite + ORM достаточно )

О. Спецы набижали. Значит и я вставлю 5 коп.

Итак, вкратце обо всем:

1. Percona не нужен, есть MariaDB;

2. Форки MySQL не нужны. На форумах висят стотысяч постов за последние 10 лет с темой «памагите восстановить крашенный innodb», и все что предлагают разрабы - это дрочево с пересозданием таблиц из FRM и discard\import. Зато «Панели с графическим представлением информации», они ведь так нужны;

3. Postgres говно. Нет, по сравнению с MySQL он конечно быстрее. Только вот это компенсируется затратами на его доизучение, а так же досадными мелочами типа ограничений количества коннектов к самому постгресу сторонними костылями. Ага, стопицот-гигабайтные базы данных менеджить можем, а пару тысяч юзеров - не. И таких примеров - десятки;

4. NoSQL - это специфичный инструмент. И да, комментирующие правы, эта приблуда хороша работы на бложиках, с миллиардами простых данных, потеря части которых ни на что не влияет. Например с лайками. Id объекта->Количество лайков. Все. Если какой-то даун станет использовать для этого реляционную БД - я бы его уволил за профнепригодность. Для серьезных транзакций естественно лучше использовать...даже не то, что стабильнее, а то что вероятнее всего восстановить после сбоя. Или даже в файлах;

5. Главное не база, а архитектура твоего приложения. Как я уже писал выше, если кто-то будет использовать мускуль для записи лайков - то разумеется это будет лютый фейл. Никто не мешает оптимизировать данные, писать на два сервера сразу, а то и использовать две БД сразу - реляционную для хранения настроек приложения и краш-чувствительных данных, и noSQL для всяких реалтаймовых чатиков, лайков и прочих поле-значение данных;

7. Percona не нужен А стоп, уже было :)

а вот твоя mongodb ещё как падала а когда её запускаешь после краша эта тварь вроде как уже запустилась а соединения не принимает довольно долго после этого а однажды и вовсе не запустилась, админ восстанавливал всё из бэкапа.

Напомнило ситуацию, когда не хотела запускаться кассандра. Так решили просто удалить журнал коммитов... Да, она тогда сразу запустилась)

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

Какое доизучение? Доизучение после изучения чего?

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

Ты имеешь ввиду 2,000 которые создаются CREATE USER / CREATE ROLE? Если да то я даже представить немогу нахер столько их делать.

Postgres говно

А что не говно?

А что не говно?

Oracle, конечно же.

Ничего не могу сказать, в глаза не видел. Знаю только что проприетарщина. А на что конкретно способен oracle из того чего не могут делать open source БД?

Доизучение после MySQL, который кагбе более популярен и прост в настройке, а посему изучаем и юзаем до тех пор, пока не требуется нечто более.

Я имею в виду highload.

На удивление с высокими нагрузками отлично справляется MSSQL. Плюс удобный. Хоть и большинство настроек делаются мышкованием.

Что имеется ввиду под нагрузками: 100500 транзакций одновременно или работа с большими базами? Меня вот, например, в MSSQL напрягают блокировки. Вместо блокировки одной записи оно часто всю таблицу блочит :(

С чего это после MySQL? Если ты конкретно выбрал MySQL а потом когда ты задолбался с этим поделием тебе пришлось перейти на PostgreSQL не значит что все проходят по такому же пути. Чем он проще в настойке? Может быть в твоём дистрибутиве какие то проблемы с PostgreSQL, ни в gentoo ни в debian никаких сложностей не обнаружил.

MSSQL это микрософт? Спасибо не надо. Наверняка ещё и с закрытыми кодами да наверняка ещё и платный. Скажи НЕТ проприетарщине и говно поделиям типа mysql, да здраствует PostgreSQL: the world's most advanced open source database.

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

С того, что я объяснил. Никто не изучает серверы БД. Это всего лишь сопутствующий инструмент для большинства людей. Изучают язык программирования. Чаще всего это PHP. Затем изучают реализации работы с БД. И так уж повелось что в 95% учебниках, в 100% примеров используется MySQL. Начиная с установки LAMP, и завершая хитрожопыми выборками на диалекте MySQL.

MSSQL это именно микрософт. Ну так вы определяйтесь, что для вас в приоритете - открытость, или удобство и скорость работы. Шашечки, или ехать.

И напоследок, скажите лучше НЕТ говнокодингу который будет плющить даже Postgres.

Что имеется ввиду под нагрузками: 100500 транзакций одновременно или работа с большими базами? Меня вот, например, в MSSQL напрягают блокировки. Вместо блокировки одной записи оно часто всю таблицу блочит :(

100500 транзакций одновременно. Я честно говоря не знаю что там и кого блочит, однако когда админы перевели хостинговый проект на MSSQL (самописная контрольная панель с кучей наворотов) - тормоза ушли полностью и целиком. Падения тоже. Ну и плюс настройка стала удобнее. Не в том плане что проводится мышкой, а в том плане что каждый параметр описан, и имеет свое значение. В случае с MySQL к примеру я, вынужден был бы изучать какие существуют настройки, какая настройка на что влияет, и методом тыка включать эти настройки в my.cnf. В случае MSSQL я буду просто менять их значения, иными словами буду думать больше над самим проектом, а не над настройкой env.

Чаще всего это PHP.

Зря ты это сказал. Щас набежит толпа php хейтеров в тему.

И так уж повелось что в 95% учебниках, в 100% примеров используется MySQL. Начиная с установки LAMP, и завершая хитрожопыми выборками на диалекте MySQL.

По PHP существуют учебники? Я думал его просто по http://us2.php.net/manual/en/ изучают.

Да и хотя бы даже так какие «затраты на доизучение», там тот же SQL для базовых SELECT/INSERT/UPDATE/DELETE а продвинутые возможности вряд ли описываются в ваших учебниках «для чайников».

К тому же PostgreSQL проще и логичнее организован. В mysql вашем как то всё укурено, пишешь references table(id) а хрен там надо как то по другому писать но и такой вариант тоже принимается без ошибок однако в итоге не действует, вечная путаница с какими то там форматами innodb, короче ну ёё в жопу эту mysql.

Языки по манам никто не учит, тем более с нуля. К манам обращаются имея какие-то навыки, при появлении какого-то специфического нетривиального вопроса. Это все равно что учиться пользованию стиралкой по ее внутренней схеме с количеством обмоток двигателя центрифуги.

Что такое релевантность - знаем ? Как Google ранжирует сайты - знаем ? Заходите в гугль и вводите «PHP database». Думаю вопросы отпадут сами собой.

Деревья судят по плодам, и если все CMS на MySQL, все учебники на MySQL, куча утилит для MySQL - то это первый признак того что она лучше чем Postgres.

И давайте не будем за простоту и логичность. Передавать пароль в командной строке через енвайрмент или костыльный файл - ни разу не проще и уж тем более не логичнее. Впрочем за 4 года надеюсь это поменялось :)

Странная логика «mysql лучше потому что мой учебник по php заодно описывает mysql». Офигеть логика. А вот мой учебник по ruby on rails рассказывает как настроить postgresql. И что дальше?

CMS и бложики PHPшные как правило поддерживают несколько dbms, вроде бы некоторые даже имеют установочную страничку где можно выбрать тип dbms и ввести host/username/password.

Какой паролько в командной строке? Вы о чём? Подключение делается из кода, для php что то типа: pg_connect(«host=localhost dbname=dbname user=user password=password»); Переменные в environment ты можешь установить для своего удобства что бы не вводить это всё при использовании клиента psql. Не хочешь вводи каждый раз так же как и в случае с консольным клиентом mysql.

MySQL лучше, потому что когда заходишь в гугль и вводишь «PHP database» (о мускуле речи не идет, идет о датабейзе), то все ссылки в пределах пяти страниц - MySQL, и нигде ни слова о Postgres. А дальше то, что если возникнет нетривиальная задача, то в случае с MySQL найти решение будет вероятнее, чем в случае с Postgres. Это очень важно для продакшена.

CMS поддерживают только MySQL. Большинство. Некоторые конечно поддерживают PDO, но это не значит что они поддерживают Postgres, это значит что они абстрагированы от конкретной БД, и как показывает практика это является причиной тормозов, поскольку выполняются ненужные запросы.

Какой пароль в командной строке ? Ну вот например mysql -h'localhost' -u'test' -p'temp123' test_database

Для своего удобства я хочу делать как мне удобнее, а не так как считает разработчик Postgres. Лишняя задача мне ни к чему.

Причём тут гугл и php я так и не понял? Какая странная логика. В случае нетривиальных задач для PostgreSQL так же легко найти решение в том же гугле, в stackoverflow да хоть где. Ты рассуждаешь о DBMS с точки зрения пхпшника пару дней назад осилившего книжку «php with mysql for dummies». Да и софт написанный такими чайниками вряд ли имеет ценность.

Для своего удобства убери вообще авторизацию по паролю для localhost. Тогда тебе достаточно будет ввести только `psql -d test_database`. Безопасность от этого точно не пострадает т.к. когда ты вводишь то что ты написал любой другой пользователь на localhostе сможет легко увидеть твой пароль с помощью `ps auxw | grep mysql`. Если ты один на localhostе тогда пофиг. Разберись сначал а потом делай выводы, осиль две страницы доков хотя бы.

Ещё можешь ~/.pgpass создать и сохранить там пароли.

Да при том что для MySQL гуглится ОГРОМНОЕ КОЛИЧЕСТВО ОТВЕТОВ, РЕШЕНИЙ, ХУКОВ, ХАКОВ И ПРОЧЕЙ ЛАБУДЫ. В отличие от постгреса.

Я рассуждаю о базе данных с точки зрения PM, которому и в хер не впало строить аппликуху на базе данных, опыт работы с которой имеет 2.5 человека в городе. С одной стороны.

С другой стороны, с чего вы взяли что я должен что-то осиливать ? Если продукт нужно «осиливать», а не работать с ним, то пользоваться им явно не стоит. Ну вот в случае с MySQL ничего осиливать не надо. В случае с MSSQL тем более. Безопасность на локалхосте - это отдельная тема, мы здесь обсуждаем БД.

Ещё можешь ~/.pgpass создать и сохранить там пароли.

Передавать пароль в командной строке через енвайрмент или костыльный файл - ни разу не проще

Ну вот в случае с MySQL ничего осиливать не надо.

Как не надо? Там тот же SQL только со множеством тёмных углов. Да вобще нафига тебе консольный клиент, вот pgwebadmin осиливать не надо или mysqlwebadmin в твоём случае. Раз для тебя так сложно осилить какую то авторизацию в командной строке зачем ты вообще полез в программированию. Иди окончи ПТУ пока не поздно на каменщика или сантехника, пойдёшь на стройке поработаешь, денег больше принесёшь чем полторы копейки которые платят таким неосиляторам. Осилить ничего не могут но нет же всё равно в офис ломятся штаны протирать за полторы копейки. Засрали весь интернет своим говнокодингом.

А я все ждал, когда же начнутся проявления агрессии, характерной для сектантов :)

Открою тайну. Большие деньги платят не осиляторам\неосиляторам, а за продукт. Заказчику плевать, Postgres там или MySQL. Ему важно время и ему важны деньги.

Вот нашел я проект «требуется система для мониторинга серверов. нетвиз не предлагать». Заинтересовался. Пошел гуглить инструменты. Видел всякие перлы, питоны, пыхи. Первый изобиловал всякими непонятными знаками, ^(.*)$, лабуда какая-то. Второй достал меня своими отступами. А вот третий на удивление оказался простым и понятным. Слова на английском языке, конструкции начинаются с { и заканчиваются } совсем как в джаваскрипте школьном. Затем встал вопрос о хранении данных. Работа с файлами мне не понравилась, поэтому я загуглил о базах данных. Все страницы в гугле меня направляли на MySQL. И правда. Все изучение MySQL происходило в процессе написания проектика. И было легким. Никаких подводных камней. Написано «apt-get install mysql-server», так оно и заработало. Через недельку я сдал проектик заказчику и получил свои пять тыщ долларов. Еще через полгода клиент попросил добавить туда пару фич, и я добавил.

А вы говорите нужно что-то осиливать )))

Где ты тут увидел агрессию? Никакой агрессии нет. Всего лишь дельный совет. Хорошего сантехника днём с огнём не сыскать зато офисные неосиляторы куда ни плюнь. Они не хотят ничего осиливать а вместо этого сочиняют фантазии про 5 тысяч за неделю изучения пхп с mysqlом.

Это не фантазия, а типичный день на freelancer.com: https://pp.userapi.com/c637331/v637331443/358f8/zRTlBobdBaA.jpg

Но суть даже не в этом. Вы так и не поняли, почему некоторые вещи становятся популярными и поддерживаемыми в итоге, а некоторые остаются маргинальщиной.