forum.opennet.ru - "Для MongoDB представлено хранилище в оперативной памяти Perc..." (35)

форумы

помощь

поиск

регистрация

вход/выход

слежка

"Для MongoDB представлено хранилище в оперативной памяти Perc..."

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

"Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
Сообщение от opennews (??) on 17-Авг-16, 08:56
Компания «Перкона» (Percona) объявила (https://www.percona.com/about-percona/newsroom/press-release...) о выпуске Percona Memory Engine (https://www.percona.com/software/mongo-database/percona-memo...) для MongoDB, открытого in-memory хранилища для Percona Server для MongoDB. Хранилище в оперативной памяти на базе движка хранения WiredTiger (http://www.wiredtiger.com/) предусмотрено в MongoDB 3.2 Enterprise Edition, но отсутствует в MongoDB Community Edition. Percona Memory Engine для MongoDB предоставляет возможность без дополнительных затрат использовать аналогичное хранилище в Percona Server для MongoDB, бесплатной открытой альтернативе MongoDB Community Edition с расширенными возможностями. Исходные тексты продукта опубликованы (https://github.com/percona/percona-server-mongodb) на 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) сокращает время выполнения автоматизированных тестов. URL: https://www.percona.com/about-percona/newsroom/press-release... Новость: http://www.opennet.me/opennews/art.shtml?num=44978
Ответить \| Правка \| Cообщить модератору

Оглавление

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 08:56 , 17-Авг-16, (1)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 09:15 , 17-Авг-16, (2)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 09:19 , 17-Авг-16, (3) +1

Для MongoDB представлено хранилище в оперативной памяти Perc..., rob pike, 10:13 , 17-Авг-16, (4) +2
Для MongoDB представлено хранилище в оперативной памяти Perc..., Вадик, 11:22 , 17-Авг-16, (5)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Forth, 13:47 , 17-Авг-16, (6)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 14:44 , 17-Авг-16, (9)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Forth, 14:47 , 17-Авг-16, (10)

Для MongoDB представлено хранилище в оперативной памяти Perc..., путукфд, 16:11 , 17-Авг-16, (12)

Для MongoDB представлено хранилище в оперативной памяти Perc..., rob pike, 18:39 , 17-Авг-16, (16) +2

Для MongoDB представлено хранилище в оперативной памяти Perc..., Forth, 19:32 , 17-Авг-16, (17) +4

Для MongoDB представлено хранилище в оперативной памяти Perc..., rob pike, 19:41 , 17-Авг-16, (18) +1

Для MongoDB представлено хранилище в оперативной памяти Perc..., Forth, 19:56 , 17-Авг-16, (19)

Для MongoDB представлено хранилище в оперативной памяти Perc..., rob pike, 20:30 , 17-Авг-16, (20)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Forth, 21:25 , 17-Авг-16, (21)

Для MongoDB представлено хранилище в оперативной памяти Perc..., rob pike, 23:13 , 17-Авг-16, (22)

Для MongoDB представлено хранилище в оперативной памяти Perc..., путукфд, 16:11 , 17-Авг-16, (11)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 17:45 , 17-Авг-16, (14)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Лютый жабист_, 05:26 , 22-Авг-16, (33)
Для MongoDB представлено хранилище в оперативной памяти Perc..., Лютый жабист_, 11:19 , 22-Авг-16, (35)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Лютый жабист_, 05:22 , 22-Авг-16, (32)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 14:26 , 17-Авг-16, (7) –1

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 14:41 , 17-Авг-16, (8) +1

Для MongoDB представлено хранилище в оперативной памяти Perc..., anonimnous, 17:52 , 17-Авг-16, (15)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 23:44 , 17-Авг-16, (24)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 18:20 , 19-Авг-16, (28)
Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 10:43 , 20-Авг-16, (29)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 18:41 , 20-Авг-16, (30)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 13:20 , 21-Авг-16, (31)

Для MongoDB представлено хранилище в оперативной памяти Perc..., rob pike, 23:17 , 17-Авг-16, (23)

Для MongoDB представлено хранилище в оперативной памяти Perc..., анонимУася, 09:49 , 18-Авг-16, (25)
Для MongoDB представлено хранилище в оперативной памяти Perc..., Лютый жабист_, 10:50 , 22-Авг-16, (34)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 10:23 , 19-Авг-16, (26)

Для MongoDB представлено хранилище в оперативной памяти Perc..., Aleks Revo, 17:06 , 17-Авг-16, (13)
Для MongoDB представлено хранилище в оперативной памяти Perc..., Аноним, 18:19 , 19-Авг-16, (27)

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

1. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 17-Авг-16, 08:56

Осталось добавить сервер приложений на lua и будет похоже на Tarantool.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 17-Авг-16, 09:15

https://softinstigate.atlassian.net/wiki/display/RH/Home

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +1 +/–

Сообщение от Аноним (??) on 17-Авг-16, 09:19

Осталось отказаться от сохранения JSON-структуры при хранении и реализовать SQL вместо кривого собственного языка запросов. А еще неплохо бы обеспечить хоть какую-нибудь транзакционность. И можно будет пользоваться....

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +2 +/–

Сообщение от rob pike on 17-Авг-16, 10:13

> 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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Вадик (??) on 17-Авг-16, 11:22

Как бы надо уметь разделять инструменты. Мы в монге храним данные о клиентах и в целом атомарности на уровне документа достаточно для 99% задач. Для денег юзаем postgresql.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Forth (ok) on 17-Авг-16, 13:47

Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 17-Авг-16, 14:44

Для автоматического масштабирования, очевидно же.
В рамках одного сервера монга нафиг не нужна.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Forth (ok) on 17-Авг-16, 14:47

> Для автоматического масштабирования, очевидно же.
> В рамках одного сервера монга нафиг не нужна.
Это сколько должно быть серверов, чтобы это было нужно? 100? 1000?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от путукфд on 17-Авг-16, 16:11

>> Для автоматического масштабирования, очевидно же.
>> В рамках одного сервера монга нафиг не нужна.
> Это сколько должно быть серверов, чтобы это было нужно? 100? 1000?
from 3.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

16. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +2 +/–

Сообщение от rob pike on 17-Авг-16, 18:39

Горизонтальное масштабирование для СУБД это по большей части уже пережитки прошлого.
Множество ядер, NVMe и NVDIMM storage, несколько терабайт RAM по вполне некосмическим ценам во вполне стандартном сервере - это уже настоящее (про ближайшее будущее можно посмотреть, например, http://www.snia.org/nvmsummit2016).
Миллион TPS это уже обыденное явление - http://www.slideshare.net/ssuser50a356/postgresql-on-sasssdn...
Так что MongoDB с "криво, косо, ненадежно, НО WEBSCALE!!!11" с технической точки зрения перспективы имеет не лучшие.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

17. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +4 +/–

Сообщение от Forth (ok) on 17-Авг-16, 19:32

> Горизонтальное масштабирование для СУБД это по большей части уже пережитки прошлого.
> Множество ядер, NVMe и NVDIMM storage, несколько терабайт RAM по вполне некосмическим
> ценам во вполне стандартном сервере - это уже настоящее (про ближайшее
> будущее можно посмотреть, например, http://www.snia.org/nvmsummit2016).
> Миллион TPS это уже обыденное явление - http://www.slideshare.net/ssuser50a356/postgresql-on-sasssdn...
Вот-вот. Кластер постгресов в кучей синхронных слейвов только на чтение, и жирным мастером с NVMe: миллион tps (с ACID) и хорошая масштабируемость на чтение. Зачем этот цирк с NoSQL?
> Так что MongoDB с "криво, косо, ненадежно, НО WEBSCALE!!!11" с технической точки
> зрения перспективы имеет не лучшие.
+1

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +1 +/–

Сообщение от rob pike on 17-Авг-16, 19:41

Да и куда тот кластер? На чтение в RAM влезут все 99% горячих данных, на том же сервере. Память нынче дешева.
Жирность мастера с NVMe тоже преувеличена, на Хетцнерах их уже по сотке евро торгуют, с Xeon и 64GB RAM - и задачу которой на запись этого с нормально настроенным PostgreSQL этого не хватит, искать надо днем с огнем.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Forth (ok) on 17-Авг-16, 19:56

> Да и куда тот кластер? На чтение в RAM влезут все 99%
> горячих данных, на том же сервере. Память нынче дешева.
Памяти много, а процессоров может не хватить для обработки запросов, машину с 256GB памяти и двумя 6-ядерными Xeon дешевле купить намного, чем с 4-мя 10-ти ядерными :)
Очень много конкурирующих за ядра процессов - большая сатурация кэша.
> Жирность мастера с NVMe тоже преувеличена, на Хетцнерах их уже по сотке
> евро торгуют, с Xeon и 64GB RAM - и задачу которой
> на запись этого с нормально настроенным PostgreSQL этого не хватит, искать
> надо днем с огнем.
Дык для той самой масштабируемости, про которую все говорят, но которую мало кто трогал вживую :)

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от rob pike on 17-Авг-16, 20:30

Если для обработки OLTP-запросов не хватает именно процессоров, то это очень странный OLTP. Не хватает их на OLAP и ETL, которые масштабируются без каких-либо проблем любым желаемым образом.
Процессов - по числу ядер, какой смысл больше? Для мультиплексирования перед постгресом есть pg_bouncer.
> для той самой масштабируемости, про которую все говорят, но которую мало кто трогал вживую
Это обычное явление. Avito справляется, но для типичного Анонима это несерьезно, нужен webscale.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Forth (ok) on 17-Авг-16, 21:25

> Если для обработки OLTP-запросов не хватает именно процессоров, то это очень странный
> OLTP. Не хватает их на OLAP и ETL, которые масштабируются без
> каких-либо проблем любым желаемым образом.
> Процессов - по числу ядер, какой смысл больше? Для мультиплексирования перед постгресом
> есть pg_bouncer.
Бывает жирное OLTP, с вдумчивой возней, вплоть до "если a!=b попрошу a по FDW оттудова, потом продолжу" :)
Но вообще согласен конечно, достаточно хорошей машины и второй в резерве для отказоустойчивости.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от rob pike on 17-Авг-16, 23:13

Если с FDW, да еще и адаптер на Multicorn за полчаса сделан - можно и не в то упереться, конечно.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

11. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от путукфд on 17-Авг-16, 16:11

>Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?
Schemaless. REST from scratch. Horizontal scaling.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

14. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 17-Авг-16, 17:45

https://www.youtube.com/watch?v=b2F-DItXtZs

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

33. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Лютый жабист_ on 22-Авг-16, 05:26

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

35. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Лютый жабист_ on 22-Авг-16, 11:19

"Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?"
на таблице с несчастными 100млн записей
select count(*) from data;
быстрый ПГ впал в кому на 15 минут, при этом заметно просадив скорость выборок.
В монге любой размер таблицы и ответ за пару сек.
Бэкап монга делает в десятки раз быстрее, чем ПГ и Оракле. При этом совершенно незаметно на скорости отдачи инфы.
Про alter table с 100-1000 млн записей у ПГ и Оракле я промолчу.
При этом задач где монго в разы медленнее ещё не встечал. На несколько десятков процентов - да.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

32. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Лютый жабист_ on 22-Авг-16, 05:22

Профдеформация?! После 15 лет с SQL, считаю
db.persons.find().limit(1).sort({$natural:-1})
просто сказкой. Не буду напоминать, что у всех РДБМСов даже банальный .limit() делается у каждого по своему. У Оракле ещё и с приседаниями, т.к. rownum отсекает до сортировки. В сад такие "стандарты"!
С точки зрение прогера - JDBC многословен просто до одурения, то что в монге делается 5 словами, в JDBC полстраницы кода. Про гребублю с preparedStatements + select молчу, когда надо искать с переменным количеством критериев ты вынужден делать отдельные ps.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Для MongoDB представлено хранилище в оперативной памяти Perc..." –1 +/–

Сообщение от Аноним (??) on 17-Авг-16, 14:26

Вот бы еще разработчики PostgrerSQL последовали данному примеру, ломаются уже который год со всякими бестолковыми отговорками

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +1 +/–

Сообщение от Аноним (??) on 17-Авг-16, 14:41

Отговорки у них толковые, там архитектурно сейчас некуда пришить storage engines.
Но можно использовать FDW. Я так в redis из постгреса хожу. Извращение, но работает!

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

15. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от anonimnous on 17-Авг-16, 17:52

Причём здесь механизм движков? Можно в рамках текущего движка реализовать возможность выбора устройства хранения данных

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

24. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 17-Авг-16, 23:44

полноценный ACID версионник в памяти нафиг не нужен, а не полноценный - это уже не в рамках

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 19-Авг-16, 18:20

ACID в inmemory вообще не нужен, в чем проблема?

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

29. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 20-Авг-16, 10:43

Это всё ограниченность мышления, такие вещи решать только конечному пользователю, нужен ACID или нет. База в первую очередь должна предоставить возможность выбора устройства хранения данных. А с новыми ssd, которые работают через интерфейс оперативной памяти, Postgresql, в отличие от теперь уже всех других баз, работать не будет.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

30. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 20-Авг-16, 18:41

логинишься ты на gmail, а там перед загрузкой мейлбокса вопрос "нужен вам ACID или нет". "конечный пользователь", ага

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 21-Авг-16, 13:20

Конечный пользователь базы данных - администратор базы данных. А "логинишься ты на gmail" - это конечный пользователь сервиса gmail

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

23. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от rob pike on 17-Авг-16, 23:17

Совсем не извращение.
Как и, например, бизнес-логика на нормальных ЯП внутри СУБД.
Намного большее извращение - это испольтзовать тот же PostgreSQL как "dumb storage" и писать отдельные "серверы бизнес-логики", в которых 80% занимает кривая, косая и забагованная реализация той функциональности (прежде всего связанная с транзакциями и целостностью), которая в СУБД уже есть.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

25. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от анонимУася (ok) on 18-Авг-16, 09:49

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

34. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Лютый жабист_ on 22-Авг-16, 10:50

"серверы бизнес-логики", в которых 80% занимает кривая, косая и забагованная реализация той функциональности (прежде всего связанная с транзакциями и целостностью), которая в СУБД уже есть."
Что за appserver-ы не умеющие JTA? Если есть, зачем их взяли, когда есть полностью бесплатные и опенсорсные? По количеству разнообразнейших либ промышленного качества никакому СУБД не угнаться за жабой.
На моих workload-ах жабовый аппсервер по скорости дерёт Оракла с его plsql в десятки раз. Скорость разработки на plsql чего-то более сложного чем полстранички кода тоже в разы дольше.
Так что ты всё правильно говоришь с точностью до наоборот.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 19-Авг-16, 10:23

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Aleks Revo (ok) on 17-Авг-16, 17:06

Пользуйтесь, не стесняйтесь - как раз для всего вышеперечисленного создавалось.
http://www.garret.ru/imcs/user_guide.html
Ничем не хуже, даже почти такие же извращения с запросами )))
А если совсем уже хочется странного, то вот: https://wiki.postgresql.org/images/6/65/Pgopencl.pdf

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

27. "Для MongoDB представлено хранилище в оперативной памяти Perc..." +/–

Сообщение от Аноним (??) on 19-Авг-16, 18:19

В свое время только по этой причине и не перешли на постги, а с появлением tokudb смысл и вовсе отпал

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
Сообщение от Аноним (??) on 17-Авг-16, 08:56
Осталось добавить сервер приложений на lua и будет похоже на Tarantool.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 17-Авг-16, 09:15
	https://softinstigate.atlassian.net/wiki/display/RH/Home
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

3. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+1 +/–
Сообщение от Аноним (??) on 17-Авг-16, 09:19
Осталось отказаться от сохранения JSON-структуры при хранении и реализовать SQL вместо кривого собственного языка запросов. А еще неплохо бы обеспечить хоть какую-нибудь транзакционность. И можно будет пользоваться....
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+2 +/–
	Сообщение от rob pike on 17-Авг-16, 10:13
	> 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
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Вадик (??) on 17-Авг-16, 11:22
	Как бы надо уметь разделять инструменты. Мы в монге храним данные о клиентах и в целом атомарности на уровне документа достаточно для 99% задач. Для денег юзаем postgresql.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Forth (ok) on 17-Авг-16, 13:47
	Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	9. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 17-Авг-16, 14:44
	Для автоматического масштабирования, очевидно же. В рамках одного сервера монга нафиг не нужна.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	10. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Forth (ok) on 17-Авг-16, 14:47
	> Для автоматического масштабирования, очевидно же. > В рамках одного сервера монга нафиг не нужна. Это сколько должно быть серверов, чтобы это было нужно? 100? 1000?
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	12. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от путукфд on 17-Авг-16, 16:11
	>> Для автоматического масштабирования, очевидно же. >> В рамках одного сервера монга нафиг не нужна. > Это сколько должно быть серверов, чтобы это было нужно? 100? 1000? from 3.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	16. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+2 +/–
	Сообщение от rob pike on 17-Авг-16, 18:39
	Горизонтальное масштабирование для СУБД это по большей части уже пережитки прошлого. Множество ядер, NVMe и NVDIMM storage, несколько терабайт RAM по вполне некосмическим ценам во вполне стандартном сервере - это уже настоящее (про ближайшее будущее можно посмотреть, например, http://www.snia.org/nvmsummit2016). Миллион TPS это уже обыденное явление - http://www.slideshare.net/ssuser50a356/postgresql-on-sasssdn... Так что MongoDB с "криво, косо, ненадежно, НО WEBSCALE!!!11" с технической точки зрения перспективы имеет не лучшие.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	17. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+4 +/–
	Сообщение от Forth (ok) on 17-Авг-16, 19:32
	> Горизонтальное масштабирование для СУБД это по большей части уже пережитки прошлого. > Множество ядер, NVMe и NVDIMM storage, несколько терабайт RAM по вполне некосмическим > ценам во вполне стандартном сервере - это уже настоящее (про ближайшее > будущее можно посмотреть, например, http://www.snia.org/nvmsummit2016). > Миллион TPS это уже обыденное явление - http://www.slideshare.net/ssuser50a356/postgresql-on-sasssdn... Вот-вот. Кластер постгресов в кучей синхронных слейвов только на чтение, и жирным мастером с NVMe: миллион tps (с ACID) и хорошая масштабируемость на чтение. Зачем этот цирк с NoSQL? > Так что MongoDB с "криво, косо, ненадежно, НО WEBSCALE!!!11" с технической точки > зрения перспективы имеет не лучшие. +1
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	18. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+1 +/–
	Сообщение от rob pike on 17-Авг-16, 19:41
	Да и куда тот кластер? На чтение в RAM влезут все 99% горячих данных, на том же сервере. Память нынче дешева. Жирность мастера с NVMe тоже преувеличена, на Хетцнерах их уже по сотке евро торгуют, с Xeon и 64GB RAM - и задачу которой на запись этого с нормально настроенным PostgreSQL этого не хватит, искать надо днем с огнем.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	19. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Forth (ok) on 17-Авг-16, 19:56
	> Да и куда тот кластер? На чтение в RAM влезут все 99% > горячих данных, на том же сервере. Память нынче дешева. Памяти много, а процессоров может не хватить для обработки запросов, машину с 256GB памяти и двумя 6-ядерными Xeon дешевле купить намного, чем с 4-мя 10-ти ядерными :) Очень много конкурирующих за ядра процессов - большая сатурация кэша. > Жирность мастера с NVMe тоже преувеличена, на Хетцнерах их уже по сотке > евро торгуют, с Xeon и 64GB RAM - и задачу которой > на запись этого с нормально настроенным PostgreSQL этого не хватит, искать > надо днем с огнем. Дык для той самой масштабируемости, про которую все говорят, но которую мало кто трогал вживую :)
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	20. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от rob pike on 17-Авг-16, 20:30
	Если для обработки OLTP-запросов не хватает именно процессоров, то это очень странный OLTP. Не хватает их на OLAP и ETL, которые масштабируются без каких-либо проблем любым желаемым образом. Процессов - по числу ядер, какой смысл больше? Для мультиплексирования перед постгресом есть pg_bouncer. > для той самой масштабируемости, про которую все говорят, но которую мало кто трогал вживую Это обычное явление. Avito справляется, но для типичного Анонима это несерьезно, нужен webscale.
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	21. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Forth (ok) on 17-Авг-16, 21:25
	> Если для обработки OLTP-запросов не хватает именно процессоров, то это очень странный > OLTP. Не хватает их на OLAP и ETL, которые масштабируются без > каких-либо проблем любым желаемым образом. > Процессов - по числу ядер, какой смысл больше? Для мультиплексирования перед постгресом > есть pg_bouncer. Бывает жирное OLTP, с вдумчивой возней, вплоть до "если a!=b попрошу a по FDW оттудова, потом продолжу" :) Но вообще согласен конечно, достаточно хорошей машины и второй в резерве для отказоустойчивости.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	22. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от rob pike on 17-Авг-16, 23:13
	Если с FDW, да еще и адаптер на Multicorn за полчаса сделан - можно и не в то упереться, конечно.
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	11. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от путукфд on 17-Авг-16, 16:11
	>Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo? Schemaless. REST from scratch. Horizontal scaling.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	14. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 17-Авг-16, 17:45
	https://www.youtube.com/watch?v=b2F-DItXtZs
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	33. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Лютый жабист_ on 22-Авг-16, 05:26
	> Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна > mongo? PG быстрее Oracle и Mysql на десятки процентов в моих workload-ах. Монга быстрее по некоторым операциям в десяток раз ;) p.s. сколько времени занимает добавить 5 новых столбцов в PG на табличке из 1млрд записей? Как при этом проседает скорость select/update/insert? Вспоминается анекдот "папа, покажи многозадачность", "щас, дискетку доформатирую!".
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	35. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Лютый жабист_ on 22-Авг-16, 11:19
	"Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?" на таблице с несчастными 100млн записей select count(*) from data; быстрый ПГ впал в кому на 15 минут, при этом заметно просадив скорость выборок. В монге любой размер таблицы и ответ за пару сек. Бэкап монга делает в десятки раз быстрее, чем ПГ и Оракле. При этом совершенно незаметно на скорости отдачи инфы. Про alter table с 100-1000 млн записей у ПГ и Оракле я промолчу. При этом задач где монго в разы медленнее ещё не встечал. На несколько десятков процентов - да.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	32. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Лютый жабист_ on 22-Авг-16, 05:22
	Профдеформация?! После 15 лет с SQL, считаю db.persons.find().limit(1).sort({$natural:-1}) просто сказкой. Не буду напоминать, что у всех РДБМСов даже банальный .limit() делается у каждого по своему. У Оракле ещё и с приседаниями, т.к. rownum отсекает до сортировки. В сад такие "стандарты"! С точки зрение прогера - JDBC многословен просто до одурения, то что в монге делается 5 словами, в JDBC полстраницы кода. Про гребублю с preparedStatements + select молчу, когда надо искать с переменным количеством критериев ты вынужден делать отдельные ps.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору

7. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	–1 +/–
Сообщение от Аноним (??) on 17-Авг-16, 14:26
Вот бы еще разработчики PostgrerSQL последовали данному примеру, ломаются уже который год со всякими бестолковыми отговорками
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	8. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+1 +/–
	Сообщение от Аноним (??) on 17-Авг-16, 14:41
	Отговорки у них толковые, там архитектурно сейчас некуда пришить storage engines. Но можно использовать FDW. Я так в redis из постгреса хожу. Извращение, но работает!
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	15. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от anonimnous on 17-Авг-16, 17:52
	Причём здесь механизм движков? Можно в рамках текущего движка реализовать возможность выбора устройства хранения данных
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	24. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 17-Авг-16, 23:44
	полноценный ACID версионник в памяти нафиг не нужен, а не полноценный - это уже не в рамках
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	28. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 19-Авг-16, 18:20
	ACID в inmemory вообще не нужен, в чем проблема?
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	29. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 20-Авг-16, 10:43
	Это всё ограниченность мышления, такие вещи решать только конечному пользователю, нужен ACID или нет. База в первую очередь должна предоставить возможность выбора устройства хранения данных. А с новыми ssd, которые работают через интерфейс оперативной памяти, Postgresql, в отличие от теперь уже всех других баз, работать не будет.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	30. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 20-Авг-16, 18:41
	логинишься ты на gmail, а там перед загрузкой мейлбокса вопрос "нужен вам ACID или нет". "конечный пользователь", ага
	Ответить \| Правка \| ^ к родителю #29 \| Наверх \| Cообщить модератору


	31. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от Аноним (??) on 21-Авг-16, 13:20
	Конечный пользователь базы данных - администратор базы данных. А "логинишься ты на gmail" - это конечный пользователь сервиса gmail
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	23. "Для MongoDB представлено хранилище в оперативной памяти Perc..."	+/–
	Сообщение от rob pike on 17-Авг-16, 23:17
	Совсем не извращение. Как и, например, бизнес-логика на нормальных ЯП внутри СУБД. Намного большее извращение - это испольтзовать тот же PostgreSQL как "dumb storage" и писать отдельные "серверы бизнес-логики", в которых 80% занимает кривая, косая и забагованная реализация той функциональности (прежде всего связанная с транзакциями и целостностью), которая в СУБД уже есть.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору