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 ()
Последнее исправление: sudopacman (всего исправлений: 7)
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от iluha16

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

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

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

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

Ну что там масштабируется? В Postgres тоже можно иметь несколько серверов, читай https://www.postgresql.org/docs/9.5/static/high-availability.html если не веришь. Все сложности с этим связаные заключаются как раз таки в поддержке ACID транзакций т.е. в поддержке того чего в твоих хипстерских nosql вообще не предусмотрено.

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