Не позволявайте на пространствения мащаб (1000+ устройства) да ви подведе по отношение на изчислителния мащаб и/или мащаба за съхранение. Няколко десетки 35-байтови вмъквания в секунда са тривиално натоварване за всяка масова СУБД, дори работеща на хардуер от нисък клас. По същия начин 142 милиона записа на месец са само от порядъка на 1~10 гигабайта място за съхранение на месец, без никаква компресия, включително индекси.
В коментара на въпроса си казахте:
„Всичко е свързано с надеждност, мащабируемост и скорост. Много е важно решението да се мащабира лесно (автоматично разделяне на MongoDB?), просто добавяйки повече възли, а скоростта също е много важна
Надеждност? Всяка масова СУБД може да гарантира това (ако приемем, че няма да повреди данните ви и няма да се срине - вижте моето обсъждане на теоремата за CAP в долната част на този отговор). скорост? Дори и с една машина, 10~100 пъти това натоварване не би трябвало да е проблем. Мащабируемост? При текущата скорост данните за цяла година, некомпресирани, дори напълно индексирани, лесно биха се побрали в рамките на 100 гигабайта дисково пространство (по същия начин вече установихме, че скоростта на вмъкване не е проблем).
Като такъв, не виждам никаква ясна нужда от екзотично решение като NoSQL или дори от разпределена база данни - обикновена, стара релационна база данни като MySQL би била добре. Ако се притеснявате от отказ, просто настройте резервен сървър в конфигурация главен-подчинен. Ако говорим за 100 или 1000 пъти текущата скала, просто разделете хоризонтално няколко екземпляра въз основа на идентификатора на устройството за събиране на данни (т.е. {индекс на дял} ={идентификатор на устройство} по модул {брой дялове}).
Имайте предвид, че напускането на безопасните и удобни граници на света на релационните бази данни означава изоставяне както на представителния модел и неговия богат набор от инструменти . Това ще направи вашето „комплексно копаене на данни“ много по-трудно – не е нужно само да поставите данни в базата данни, но също така трябва да ги извадите.
Като се има предвид всичко това, MongoDB и CouchDB са необичайно лесни за внедряване и работа. Те също така са много забавни и ще ви направят по-привлекателни за произволен брой хора (не само програмисти - също и ръководители!).
Общата мъдрост е, че от трите NoSQL решения, които предложихте, Cassandra е най-доброто за голям обем на вмъкване (разбира се, относително казано, не мисля, че имате голям обем на вмъкване – това е проектирано да се използва от Facebook ); това се противодейства от това, че е по-трудно да се работи. Така че освен ако нямате някакви странни изисквания, които не сте споменали, бих препоръчал да не ги използвате за вашия случай на употреба.
Ако сте положително настроени за внедряване на NoSQL, може да искате да разгледате теоремата за CAP. Това ще ви помогне да изберете между MongoDB и CouchDB. Ето една добра връзка:http://blog.nahurst.com/visual-guide-to-nosql-systems. Всичко се свежда до това, което имате предвид под „надеждност“:MongoDB търгува наличността за последователност, докато CouchDB търгува последователност за наличност . (Cassandra ви позволява да прецизирате този компромис, за всяка заявка, като посочите колко сървъра трябва да бъдат записани/прочетени, за да успее едно записване/четене; АКТУАЛИЗАЦИЯ:Сега може и CouchDB, с BigCouch! Много вълнуващо...)
Успех във вашия проект.
