The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для MongoDB представлено хранилище в оперативной памяти Percona Memory Engine

17.08.2016 00:47

Компания «Перкона» (Percona) объявила о выпуске Percona Memory Engine для MongoDB, открытого in-memory хранилища для Percona Server для MongoDB. Хранилище в оперативной памяти на базе движка хранения WiredTiger предусмотрено в MongoDB 3.2 Enterprise Edition, но отсутствует в MongoDB Community Edition. Percona Memory Engine для MongoDB предоставляет возможность без дополнительных затрат использовать аналогичное хранилище в Percona Server для MongoDB, бесплатной открытой альтернативе MongoDB Community Edition с расширенными возможностями. Исходные тексты продукта опубликованы на GitHub под лицензией AGPL.

Percona Memory Engine для MongoDB обеспечивает высокую производительность при операциях чтения с предсказуемыми задержками, а также высокую производительность при операциях записи без сохранения данных на диске. Новое решение помогает сократить расходы на инфраструктуру, так как позволяет сэкономить на построении высокопроизводительного хранилища. Параметры командной строки и конфигурации Percona Memory Engine для MongoDB идентичны тем, которые используются в MongoDB 3.2 Enterprise Edition, что обеспечивает простоту перехода на Percona Server для MongoDB.

Основные примеры использования Percona Memory Engine для MongoDB:

  • Кэш приложения (Application Cache) заменяет такие сервисы, как memcached и самописные структуры данных уровня приложения. Кэш-память приложения может использовать все возможности MongoDB.
  • Аналитика в реальном времени (Real-time Analytics) использует вычисления в памяти для тех случаев, когда время отклика важнее, чем сохранение данных.
  • Сложные операции с данными (Sophisticated Data Manipulation) – решение обеспечивает более высокую производительность при сложных операциях c данными – таких, как агрегирование и MapReduce.
  • Управление сессиями (Session Management) – активные сессии пользователей хранятся в памяти для уменьшения времени отклика приложения.
  • Кратковременное состояние среды выполнения (Transient Runtime State) – хранение динамического состояния приложения.
  • Многоуровневый общий доступ к объектам (Multi-tier object sharing) упрощает общий доступ к данным в многоуровневых приложениях и приложениях, написанных на нескольких языках программирования.
  • Тестирование приложения (Application Testing) сокращает время выполнения автоматизированных тестов.


  1. Главная ссылка к новости (https://www.percona.com/about-...)
  2. OpenNews: Выпуск Percona Server для MongoDB 3.2
  3. OpenNews: Некорректно настроенные серверы MongoDB являются источником утечки 684 Тб данных
  4. OpenNews: Релиз документо-ориентированной СУБД MongoDB 3.2
  5. OpenNews: Выпущен Percona Server для MongoDB
Автор новости: Percona
Тип: Программы
Короткая ссылка: https://opennet.ru/44978-mongodb
Ключевые слова: mongodb, percona
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 08:56, 17/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Осталось добавить сервер приложений на lua и будет похоже на Tarantool.
     
     
  • 2.2, Аноним (-), 09:15, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    https://softinstigate.atlassian.net/wiki/display/RH/Home
     

  • 1.3, Аноним (-), 09:19, 17/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Осталось отказаться от сохранения JSON-структуры при хранении и реализовать SQL вместо кривого собственного языка запросов. А еще неплохо бы обеспечить хоть какую-нибудь транзакционность. И можно будет пользоваться....
     
     
  • 2.4, rob pike (?), 10:13, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ToroDB - Open source NoSQL database that runs on top of a RDBMS. Compatible with MongoDB protocol and APIs, but with support for native SQL, atomic operations and reliable and durable backends like PostgreSQL

    https://github.com/torodb/torodb

     
  • 2.5, Вадик (??), 11:22, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как бы надо уметь разделять инструменты. Мы в монге храним данные о клиентах и в целом атомарности на уровне документа достаточно для 99% задач. Для денег юзаем postgresql.
     
     
  • 3.6, Forth (ok), 13:47, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?
     
     
  • 4.9, Аноним (-), 14:44, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Для автоматического масштабирования, очевидно же.

    В рамках одного сервера монга нафиг не нужна.

     
     
  • 5.10, Forth (ok), 14:47, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Для автоматического масштабирования, очевидно же.
    > В рамках одного сервера монга нафиг не нужна.

    Это сколько должно быть серверов, чтобы это было нужно? 100? 1000?

     
     
  • 6.12, путукфд (?), 16:11, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Для автоматического масштабирования, очевидно же.
    >> В рамках одного сервера монга нафиг не нужна.
    > Это сколько должно быть серверов, чтобы это было нужно? 100? 1000?

    from 3.

     
  • 5.16, rob pike (?), 18:39, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Горизонтальное масштабирование для СУБД это по большей части уже пережитки прошлого.
    Множество ядер, NVMe и NVDIMM storage, несколько терабайт RAM по вполне некосмическим ценам во вполне стандартном сервере - это уже настоящее (про ближайшее будущее можно посмотреть, например, http://www.snia.org/nvmsummit2016).
    Миллион TPS это уже обыденное явление - http://www.slideshare.net/ssuser50a356/postgresql-on-sasssdnvmenvdimm

    Так что MongoDB с "криво, косо, ненадежно, НО WEBSCALE!!!11" с технической точки зрения перспективы имеет не лучшие.

     
     
  • 6.17, Forth (ok), 19:32, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Горизонтальное масштабирование для СУБД это по большей части уже пережитки прошлого.
    > Множество ядер, NVMe и NVDIMM storage, несколько терабайт RAM по вполне некосмическим
    > ценам во вполне стандартном сервере - это уже настоящее (про ближайшее
    > будущее можно посмотреть, например, http://www.snia.org/nvmsummit2016).
    > Миллион TPS это уже обыденное явление - http://www.slideshare.net/ssuser50a356/postgresql-on-sasssdnvmenvdimm

    Вот-вот. Кластер постгресов в кучей синхронных слейвов только на чтение, и жирным мастером с NVMe: миллион tps (с ACID) и хорошая масштабируемость на чтение. Зачем этот цирк с NoSQL?

    > Так что MongoDB с "криво, косо, ненадежно, НО WEBSCALE!!!11" с технической точки
    > зрения перспективы имеет не лучшие.

    +1

     
     
  • 7.18, rob pike (?), 19:41, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да и куда тот кластер? На чтение в RAM влезут все 99% горячих данных, на том же сервере. Память нынче дешева.
    Жирность мастера с NVMe тоже преувеличена, на Хетцнерах их уже по сотке евро торгуют, с Xeon и 64GB RAM - и задачу которой на запись этого с нормально настроенным PostgreSQL этого не хватит, искать надо днем с огнем.
     
     
  • 8.19, Forth (ok), 19:56, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Памяти много, а процессоров может не хватить для обработки запросов, машину с 25... текст свёрнут, показать
     
     
  • 9.20, rob pike (?), 20:30, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если для обработки OLTP-запросов не хватает именно процессоров, то это очень стр... текст свёрнут, показать
     
     
  • 10.21, Forth (ok), 21:25, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Бывает жирное OLTP, с вдумчивой возней, вплоть до если a b попрошу a по FDW от... текст свёрнут, показать
     
     
  • 11.22, rob pike (?), 23:13, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если с FDW, да еще и адаптер на Multicorn за полчаса сделан - можно и не в то уп... текст свёрнут, показать
     
  • 4.11, путукфд (?), 16:11, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?

    Schemaless. REST from scratch. Horizontal scaling.

     
     
  • 5.14, Аноним (-), 17:45, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.youtube.com/watch?v=b2F-DItXtZs
     
  • 4.33, Лютый жабист_ (?), 05:26, 22/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна
    > mongo?

    PG быстрее Oracle и Mysql на десятки процентов в моих workload-ах. Монга быстрее по некоторым операциям в десяток раз ;)

    p.s. сколько времени занимает добавить 5 новых столбцов в PG на табличке из 1млрд записей?
    Как при этом проседает скорость select/update/insert?
    Вспоминается анекдот "папа, покажи многозадачность", "щас, дискетку доформатирую!".

     
  • 4.35, Лютый жабист_ (?), 11:19, 22/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    "Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?"

    на таблице с несчастными 100млн записей
    select count(*) from data;
    быстрый ПГ впал в кому на 15 минут, при этом заметно просадив скорость выборок.

    В монге любой размер таблицы и ответ за пару сек.

    Бэкап монга делает в десятки раз быстрее, чем ПГ и Оракле. При этом совершенно незаметно на скорости отдачи инфы.

    Про alter table с 100-1000 млн записей у ПГ и Оракле я промолчу.

    При этом задач где монго в разы медленнее ещё не встечал. На несколько десятков процентов - да.

     
  • 2.32, Лютый жабист_ (?), 05:22, 22/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Профдеформация?! После 15 лет с SQL, считаю
    db.persons.find().limit(1).sort({$natural:-1})
    просто сказкой. Не буду напоминать, что у всех РДБМСов даже банальный .limit() делается у каждого по своему. У Оракле ещё и с приседаниями, т.к. rownum отсекает до сортировки. В сад такие "стандарты"!

    С точки зрение прогера - JDBC многословен просто до одурения, то что в монге делается 5 словами, в JDBC полстраницы кода. Про гребублю с preparedStatements + select молчу, когда надо искать с переменным количеством критериев ты вынужден делать отдельные ps.

     

  • 1.7, Аноним (-), 14:26, 17/08/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вот бы еще разработчики PostgrerSQL последовали данному примеру, ломаются уже который год со всякими бестолковыми отговорками
     
     
  • 2.8, Аноним (-), 14:41, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Отговорки у них толковые, там архитектурно сейчас некуда пришить storage engines.

    Но можно использовать FDW. Я так в redis из постгреса хожу. Извращение, но работает!

     
     
  • 3.15, anonimnous (?), 17:52, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Причём здесь механизм движков? Можно в рамках текущего движка реализовать возможность выбора устройства хранения данных
     
     
  • 4.24, Аноним (-), 23:44, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    полноценный ACID версионник в памяти нафиг не нужен, а не полноценный - это уже не в рамках
     
     
  • 5.28, Аноним (-), 18:20, 19/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ACID в inmemory вообще не нужен, в чем проблема?
     
  • 5.29, Аноним (-), 10:43, 20/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё ограниченность мышления, такие вещи решать только конечному пользователю, нужен ACID или нет. База в первую очередь должна предоставить возможность выбора устройства хранения данных. А с новыми ssd, которые работают через интерфейс оперативной памяти, Postgresql, в отличие от теперь уже всех других баз, работать не будет.
     
     
  • 6.30, Аноним (-), 18:41, 20/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    логинишься ты на gmail, а там перед загрузкой мейлбокса вопрос "нужен вам ACID или нет". "конечный пользователь", ага
     
     
  • 7.31, Аноним (-), 13:20, 21/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Конечный пользователь базы данных - администратор базы данных. А "логинишься ты на gmail" - это конечный пользователь сервиса gmail
     
  • 3.23, rob pike (?), 23:17, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Совсем не извращение.
    Как и, например, бизнес-логика на нормальных ЯП внутри СУБД.
    Намного большее извращение - это испольтзовать тот же PostgreSQL как "dumb storage" и писать отдельные "серверы бизнес-логики", в которых 80% занимает кривая, косая и забагованная реализация той функциональности (прежде всего связанная с транзакциями и целостностью), которая в СУБД уже есть.
     
     
  • 4.25, анонимУася (ok), 09:49, 18/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Как и, например, бизнес-логика на нормальных ЯП внутри СУБД.

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

     
  • 4.34, Лютый жабист_ (?), 10:50, 22/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    "серверы бизнес-логики", в которых 80% занимает кривая, косая и забагованная реализация той функциональности (прежде всего связанная с транзакциями и целостностью), которая в СУБД уже есть."

    Что за appserver-ы не умеющие JTA? Если есть, зачем их взяли, когда есть полностью бесплатные и опенсорсные? По количеству разнообразнейших либ промышленного качества никакому СУБД не угнаться за жабой.

    На моих workload-ах жабовый аппсервер по скорости дерёт Оракла с его plsql в десятки раз. Скорость разработки на plsql чего-то более сложного чем полстранички кода тоже в разы дольше.
    Так что ты всё правильно говоришь с точностью до наоборот.

     
  • 3.26, Аноним (-), 10:23, 19/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и будет так волочиться в ногах прогресса. В MySQL уже скоро найтивное партицирование будет, а они inmemory запилить не могут, который теперь есть во всех базах.
     
  • 2.13, Aleks Revo (ok), 17:06, 17/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Пользуйтесь, не стесняйтесь - как раз для всего вышеперечисленного создавалось.
    http://www.garret.ru/imcs/user_guide.html

    Ничем не хуже, даже почти такие же извращения с запросами )))

    А если совсем уже хочется странного, то вот: https://wiki.postgresql.org/images/6/65/Pgopencl.pdf

     
  • 2.27, Аноним (-), 18:19, 19/08/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В свое время только по этой причине и не перешли на постги, а с появлением tokudb смысл и вовсе отпал
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру