Механизъм за съхранение за конкретен случай

Каква база данни можете да препоръчате за такъв случай:

  1. Много вмъквания и актуализации
  2. Сложни заявки (SQL или нещо подобно)
  3. Много данни, но малко количество често достъпни (може да е в паметта)
  4. Добре е да загубите част от данните (последния час например) в случай на срив (но не всичко)

Възможни решения и проблеми с него:

  • Redis - изглежда добре, но не поддържа сложни заявки.
  • RDBMS (текущо решение) - гарантира ACID и използва много твърд диск, така че актуализациите са твърде бавни
  • RDBMS + RAM диск - ще използва OS swap, проблеми с възстановяването и като цяло изглежда не много надежден
  • MongoDB - има заключване на ниво сървър при записване, наистина ли е бързо?

database mongodb redis memory rdms
person valodzka    schedule 16.02.2011    source източник

Отговори (3)


arrow_upward
0
arrow_downward

1. Много вмъквания и актуализации (Mobgodb).

4. Добре е да загубите част от данните (последния час например) в случай на срив (но не всичко)

Незадължителните асинхронни записи в mongo ще помогнат за скоростта тук. Скоростта на вмъкване/запис в mongodb ще бъде по-бърза от sql, защото mongo първо записва всички данни в паметта и mongodb не използва транзакции.

2. Сложни заявки (SQL или нещо подобно)

Ако имате много трудни отчети, които изискват обединяване на почти всички данни, по-добре използвайте sql тук. Но ако имате нужда от трудни заявки вътре в документа, използвайте mongodb (зависи от дизайна на sql/nosql db схема)

3. Много данни, но малко количество често достъпни (може да е в паметта)

Ако има достатъчно свободна памет на сървъра, mongodb зарежда всички данни в RAM.

Тъй като съм фанатик на mongodb, ще избера MongoDb, но без конкретна задача не мога да съм сигурен, че изборът ще бъде правилен. Също така сравних само sql и mongodb, защото изобщо не съм използвал Redis.

person Andrew Orsich    schedule 16.02.2011
comment
Какво представляват заявките вътре в документа? - person valodzka; 16.02.2011
comment
Имам предвид заявки, които изискват само един документ (без обединения). - person Andrew Orsich; 16.02.2011

arrow_upward
1
arrow_downward

Релационните Mysql/Postgresql + дялове трябва да могат да решават случаите на използване. MongoDb можеше да бъде идеалното решение, освен поради 2 причини.

  • Необходима е достатъчно RAM, за да се гарантира, че прилична част от базата данни е в паметта.

  • Поддръжка на сложни заявки. Тъй като JOINS не се поддържат, трябва да се дублират данни на множество места ИЛИ JOINS ще трябва да се изпълняват в кода на приложението.

  • Изпълнение на сложни аналитични заявки. Агрегиране на данни mongodb срещу mysql

Имах подобна ситуация и оцених postgresql срещу mongodb. Избрани postgresql + дялове (разделянето е извършено по времево клеймо) поради горните причини.

Ако наборът от данни е подреден по време или ако разделянето е възможно по някакъв начин, актуализациите и заявките ще бъдат бързи.

За mysql, ако се използва MYISAM (нетранзакционно) устройство за съхранение, производителността ще се подобри допълнително за сметка на издръжливостта. За RDBMS, която не позволява изключване на транзакции, производителността все още може да бъде подобрена чрез коригиране на интервала на контролните точки и няколко други параметри, които гарантират, че транзакциите се извършват по спокоен начин. Но ако схемата може да се променя често, тогава RDBMS решенията могат да бъдат сложни.

person Anoop    schedule 19.02.2011

arrow_upward
0
arrow_downward

Сложните заявки и скоростта на вмъкване в момента не се смесват. Освен ако, разбира се, тези запитвания не са известни предварително. те ли са

person chx    schedule 16.02.2011