LINUX.ORG.RU

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

 


1

1

14 февраля компания «Перкона» (Percona), поставщик решений и услуг для MySQL® и MongoDB®, объявила о выходе обновлённых версий сразу трёх бесплатных продуктов с открытым исходным кодом: Percona Server для MongoDB 3.4, Percona Monitoring and Management 1.1 и Percona Toolkit 3.0. Все три продукта могут быть использованы вместе для достижения оптимальной производительности. GA-версии данных продуктов будут доступны после 20 февраля текущего года.

Percona Server для MongoDB 3.4:

  • Присутствуют все возможности MongoDB Community Edition 3.4 — Percona Server для MongoDB 3.4 является полностью совместимой бесплатной альтернативой с открытым исходным кодом.
  • Интегрированная подключаемая аутентификация через LDAP позволяет создать централизованный сервис аутентификации для предприятия.
  • Бесплатный аудит для отслеживания действий пользователей и процессов в базе данных с возможностью удаления конфиденциальной информации (например, такой, как имена и IP-адреса пользователей) из файлов журналов.
  • Горячее резервирование для движков хранения WiredTiger и MongoRocks защищает от потери данных в случае поломки или аварии без влияния на производительность.
  • Функция обезличивания данных, записываемых в лог, позволяющая обеспечить конфиденциальность обрабатываемой информации.
  • Два дополнительных движка хранения, отсутствующих в MongoDB Community Edition 3.4:
    • MongoRocks, движок хранения на основе RocksDB, разработан специально для значительных рабочих нагрузок, таких как в приложениях для «Интернета вещей», подходит для размещения как на собственных серверах так и в облаке.
    • Percona Memory Engine идеально подходит для вычислений в памяти, а также для других приложений, которые требуют минимальной задержки при работе с БД.

Percona Monitoring and Management 1.1:

  • Поддержка MongoDB и Percona Server для MongoDB.
  • Панели с графическим представлением информации для WiredTiger, MongoRocks и Percona Memory Engine.
  • Новые способы запуска PMM-сервера: образы для VirtualBox и Amazon Machine Images (AMI).

Percona Toolkit 3.0 предоставляет два новых инструмента для MongoDB:

  • pt-mongodb-summary (аналог pt-mysql-summary) обеспечивает быстрый обзор основных параметров для данного экземпляра MongoDB или Percona Server для MongoDB.
  • pt-mongodb-query-digest (аналог pt-query-digest для MySQL) предоставляет возможность просмотра статистики запросов для выявления и устранения неполадок.

>>> Подробности



Проверено: Shaman007 ()

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

anonymous ()
Ответ на: комментарий от theNamelessOne

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

anonymous ()

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

Siado ★★★★★ ()

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

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

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

Или вот:

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

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

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

dmxrand ()
Ответ на: комментарий от Siado

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

iluha16 ()
Ответ на: комментарий от Siado

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

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

iluha16 ()
Ответ на: комментарий от iluha16

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

Siado ★★★★★ ()
Ответ на: комментарий от iluha16

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

iluha16 ()
Ответ на: комментарий от iluha16

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

Siado ★★★★★ ()
Ответ на: комментарий от anonymous

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

WindowsXP ★★ ()
Ответ на: комментарий от Siado

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

iluha16 ()
Ответ на: комментарий от iluha16

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

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

Siado ★★★★★ ()
Ответ на: комментарий от Siado

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

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

lol.

X-Pilot ★★★★★ ()
Ответ на: комментарий от Siado

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

iluha16 ()
Ответ на: комментарий от iluha16

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

Обоснуй =)

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

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

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

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

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

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

Siado ★★★★★ ()
Ответ на: комментарий от Siado

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

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

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

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

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

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

iluha16 ()
Ответ на: комментарий от Siado

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

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

X-Pilot ★★★★★ ()
Ответ на: комментарий от X-Pilot

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

iluha16 ()
Ответ на: комментарий от X-Pilot

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

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

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

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

Siado ★★★★★ ()

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

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

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

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

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

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

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

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

vblats ()
Ответ на: комментарий от iluha16

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

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

dave ★★★★★ ()
Ответ на: комментарий от vblats

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

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

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

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

Postgres говно

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

iluha16 ()
Ответ на: комментарий от anonymous

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

iluha16 ()
Ответ на: комментарий от iluha16

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

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

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

vblats ()
Ответ на: комментарий от vblats

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

anonymous ()
Ответ на: комментарий от vblats

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

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

iluha16 ()
Ответ на: комментарий от anonymous

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

iluha16 ()
Ответ на: комментарий от iluha16

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

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

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

vblats ()
Ответ на: комментарий от anonymous

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

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

vblats ()
Ответ на: комментарий от vblats

Чаще всего это 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.

iluha16 ()
Ответ на: комментарий от iluha16

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

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

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

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

vblats ()
Ответ на: комментарий от vblats

Странная логика «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.

iluha16 ()
Ответ на: комментарий от iluha16

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

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

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

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

vblats ()
Ответ на: комментарий от vblats

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

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

iluha16 ()
Ответ на: комментарий от iluha16

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

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

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

vblats ()
Ответ на: комментарий от iluha16

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

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

vblats ()
Ответ на: комментарий от vblats

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

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

iluha16 ()
Ответ на: комментарий от iluha16

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

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

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

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

vblats ()
Ответ на: комментарий от vblats

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

iluha16 ()
Ответ на: комментарий от iluha16

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

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

vblats ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.