Дъщерният сценарий за големи данни – трябва да пресеете голямо количество данни, за да извлечете малко “ самородно парче“ информация. Освен това трябва да бъде направено във възможно най-кратък период от време, бизнесът ви зависи от това. Исторически, използвайки традиционната технология за управление на релационна база данни (RDBMS), този вид сценарий изисква голям екип и инвестиция на време и пари. Повечето традиционни RDBMS мащабират само вертикално, така че трябва да продължите да купувате все по-големи машини, за да намалите времето си за изпълнение. Появата на публични облаци и NoSQL бази данни като MongoDB напълно наруши начина, по който екипите мислят за този сценарий.
Наскоро един от клиентите ни дойде при нас с интересен проблем. Те периодично трябваше да изпълняват наистина сложна заявка, която да сканира целия им набор от данни. Тази заявка беше почти сканиране на колекция което докосна всеки документ в колекцията и включваше следните подробности:
- Общите данни бяха около 100 GB.
- Безопасността на данните не беше проблем, тъй като основното копие на данните се намираше другаде.
- Скоростта на заявката беше изключително важна. Целта беше да може да се изпълни цялата заявка в рамките на 10-15 минути.
- Системата трябваше да работи само когато се изпълнява заявката (минимизиране на разходите).
Поради последното изискване имаше смисъл цялата система да се стартира в публичен облак. Машините се включват само за няколко часа всяка седмица, за да се актуализират данните и да се изпълни заявката. Клиентът вече се чувстваше добре с Amazon EC2, така че беше взето решение за прототип на системата в AWS.
Най-добрата конфигурация за постигане на тази цел беше „разчленено“ разгръщане на MongoDB. Ето конфигурацията, на която се спряхме:
- 3 фрагмента – всеки шард има самостоятелен екземпляр (r3.xlarge) с 30 GB RAM
- 1 конфигурационен сървър
- 1 шард рутер (m3.xlarge) с 15 GB RAM
Няколко неща, които трябва да посочим относно нашия избор:
-
Самостоятелен срещу набор от реплики
Безопасността на данните не е важно изискване тук, тъй като основните данни се съхраняват в отделна система. Затова използвахме самостоятелни сървъри вместо набор от реплика, за да спестим разходите.
-
3 конфигурационни сървъра срещу 1 конфигурационен сървър
причината е както по-горе. Безопасността на данните не е важен въпрос. В типична производствена среда бихме използвали три конфигурационни сървъра.
Истинската красота на тази конфигурация е, че поради разчленената конфигурация почти всичките 100 GB данни се съхраняват изцяло в паметта. Така че по същество това, което изпълнявате, е сканиране „в паметта“. Това драстично намали времето за изпълнение на заявката от няколко часа на по-малко от 10 минути. Използването на публичния облак също драстично намали капиталовите инвестиции, тъй като плащате само за машините, когато те работят.
Това е доста драматична промяна в начина, по който екипите се справят с този сценарий през последното десетилетие. Така че, ако сте в бизнеса с „намиране на игла в купа сено“, помислете за Cloud + NoSQL!
Както винаги, ако имате въпроси, можете да се свържете с нас на [email protected].
