MongoDB Atlas эсвэл DynamoDB: 6 мс latency уян query-г орлохгүй

Хайлтын нөхцөл нь байнга өөрчлөгддөг бүтээгдэхүүний каталогт MongoDB Atlas, харин түлхүүрээр тогтмол уншдаг өгөгдөлд DynamoDB илүү тохирч болно. Altoros-ийн 2023 оны YCSB тайланд унших, шинэчлэх хүсэлт тэнцүү холилдсон ачаалал дээр DynamoDB-ийн саатал ойролцоогоор 6 мс, MongoDB Atlas-ийнх 3 зангилаатай тохиргоонд 25.67 мс, 18 зангилаатайд ойролцоогоор 8 мс байв. Эдгээр нь түлхүүрээр хандах туршилтын үр дүн бөгөөд барааг олон шинжээр шүүх асуулгын хугацаа биш.

Энэ сонголтод өгөгдлийн бүтэц, шинээр нэмэгдэх асуулга, ачааллын хэлбэлзэл болон нийт төлбөр хамт нөлөөлнө. Тухайлбал, барааны ID-гаар хуудсыг нээх хүсэлт ба худалдан авагчийн сонгосон шинжүүдээр бүх каталогоос шүүх хүсэлт өөр индекс шаарддаг. Нэг хүсэлтийн хурдыг харьцуулахаас өмнө хэрэглээний гол хандалтын зам аль нь болохыг ялгах хэрэгтэй.

Өгөгдлийн загвар асуулгын уян байдлыг хэрхэн өөрчилдөг вэ?

MongoDB-ийн баримт бүр ижил талбартай байх албагүй. MongoDB-ийн индексийн тайлбар олон талбарын нийлмэл индекс, массивын multikey индекс, талбарын нэр нь ялгаатай баримтад зориулсан wildcard индексийг тус тус тодорхойлдог. Ийм сонголт нь каталогт шинэ төрлийн бараа, шинэ шинж нэмэгдэхэд асуулгыг өөрчлөх боломж өгнө. Гэхдээ индексийн талбарын дараалал чухал; дурын шүүлтүүрийг ямар ч төлөвлөлтгүйгээр хурдан ажиллуулна гэсэн үг биш.

DynamoDB-д хүсэлтүүдийг partition key болон шаардлагатай үед sort key-ийн дагуу урьдчилан зураглах нь илүү чухал. AWS-ийн онлайн дэлгүүрийн загварт бүтээгдэхүүнийг ID-гаар авдаг боловч бүтээгдэхүүний ID, огнооны хүрээгээр захиалга олох шинэ хүсэлтэд global secondary index нэмдэг. Энэ жишээ нь барааг шинжээр шүүх тухай биш; шинэ хайлтын чиглэл гарвал түлхүүр эсвэл индексийн загварт ажил нэмэгдэх механизмыг харуулж байна.

Индекс нэмэх нь зөвхөн унших замыг өөрчилдөггүй. Индекст хамрагдах өгөгдөл хадгалагдаж, бичилттэй хамт шинэчлэгдэнэ; түгээмэл бус шүүлтүүр бүрт индекс үүсгэх шийдвэр хадгалалт, бичилт, удирдлагын өртөгтэй. Atlas-д ч индексийн тоо өсөх тусам эдгээр нөөцийг тооцно. Ялгаа нь шинэ асуулгыг баримтын талбарт тулгуурлан илэрхийлэх боломж болон урьдчилан тогтоосон түлхүүрийн замд түүнийг багтаах ажлын хэмжээнд оршино.

Гурван схемд хандалтын зам хэрхэн харагдах вэ?

Онлайн худалдааны каталог

Нөхцөлт хувцасны каталогт бүтээгдэхүүний ID-гаар дэлгэрэнгүй мэдээлэл авах, ангилал дотор хэмжээ ба өнгөөр шүүх, дараа нь материал нэмэх гэсэн хүсэлтүүд байна гэж үзье. Эхний хүсэлт тогтмол түлхүүртэй тул DynamoDB-д энгийн загвар болно. Харин шүүлтүүрийн хослол тогтмол өөрчлөгдөж, шинэ ангилал бүр өөр шинжтэй бол Atlas-ийн баримтын загвар болон тохирох индексүүд илүү уян сонголт болж магадгүй.

DynamoDB ийм каталогийг ажиллуулж чадна, гэхдээ хамгийн их хэрэглэгдэх жагсаалт ба шүүлтүүрийг урьдчилан тодорхойлох шаардлага нэмэгдэнэ. Шинэ шинжийг зүгээр л барааны бичлэгт хадгалж болох ч тэр шинжээр бүх барааг үр ашигтай олох нь тусдаа асуудал. Каталогийн архитектурыг бүтээгдэхүүний хуудсыг нээх хүсэлтээр л үнэлбэл худалдан авагчийн хайлтын жинхэнэ өртөг харагдахгүй.

Үйл явдлын бүртгэл

Нөхцөлт event log-д нэг хэрэглэгчийн үйл явдлыг цагийн дарааллаар авах нь үндсэн хүсэлт гэж үзвэл хэрэглэгчийн ID-г partition key, цагийг sort key болгох DynamoDB загвар ойлгомжтой. Ийм бүтэц нь хэрэглэгчийн түүхийн тодорхой хэсгийг уншихад нийцнэ. Гэхдээ бүх хэрэглэгчээс нэг төрлийн үйл явдлыг хугацаагаар хайх шинэ шаардлага гарвал анхны түлхүүр тэр хүсэлтийг шууд шийдэхгүй; нэмэлт хандалтын зам хэрэгтэй болно.

Atlas-д үйл явдлын төрөл, хугацаа зэрэг талбарт индекс төлөвлөж, дараа гарсан хайлтыг дэмжих боломж бий. Бүртгэл байнга нэмэгддэг бол индекс бүрийн хадгалалт болон шинэчлэлтийн өртөг мөн нэмэгдэнэ. Тиймээс ховор хэрэглэгдэх өргөн хайлт уу, эсвэл хэрэглэгч бүрийн дараалсан түүхийг тогтмол унших уу гэдэг ялгаа энд үйлчилгээний нэрээс илүү шийдвэрлэх ач холбогдолтой.

Хэрэглэгчийн профайл

Нөхцөлт profile сангаас хэрэглэгчийн ID-гаар нэг бичлэг авч, хэдхэн талбарыг шинэчилдэг бол DynamoDB-ийн түлхүүрт тулгуурласан зам тохиромжтой. Профайлын талбар өөрчлөгддөг байсан ч тэдгээрээр хэрэглэгчдийг хайх шаардлагагүй бол Atlas-ийн өргөн асуулгын боломж шийдвэрт бага жинтэй. Энэ тохиолдолд ачааллын хэмжээ, хэлбэлзэл болон төлбөрийн загвар илүү чухал болж болно.

Харин хэрэглэгчдийг төлөв, сонирхол эсвэл бусад өөрчлөгдөх шинжээр байнга бүлэглэж хайдаг бол profile нь каталогтой төстэй асуулгын асуудал үүсгэнэ. Тийм хайлт үндсэн бүтээгдэхүүний үйлдэл үү, эсвэл тусдаа тайлангийн ажил уу гэдгийг ялгавал өгөгдлийн санд ямар индекс хэрэгтэй нь тодорхой болно. Хувийн мэдээлэлд хэн хандахыг шийдэх зөвшөөрлийн загвар энэ техникийн сонголттой хамт төлөвлөгдөх ёстой.

Нийтлэгдсэн саатал ямар ачааллыг хэмжсэн бэ?

Дээрх хурдны хэмжилтэд өгөгдлийг түлхүүрээр уншиж, шинэчилсэн; каталогийн өөрчлөгдөх шүүлтүүрийг түүнтэй адилтгаж болохгүй. Туршилтад DynamoDB-г provisioned хүчин чадлаар ажиллуулж, автомат өсгөлтийг унтраасан тул тогтоосон хэмжээнээс давсан ачаалалд хүсэлтүүд амжилтгүй болсон. Амжилттай хүсэлтийн саатлыг дангаар нь харахад эдгээр алдаа хэрэглэгчид үзүүлэх нөлөө далд үлдэнэ.

Atlas-ийн зангилааны тоо өсөхтэй хамт туршилтын өгөгдлийн хэмжээ ч өссөн. Иймээс хоёр тохиргооны саатлын зөрүүг зөвхөн зангилаа нэмсний үр ашиг гэж тайлбарлах боломжгүй. Түүнчлэн тайлангийн унших, богино хүрээний бичлэг авах, шүүж хуудаслах ачааллууд өөр өөр хүсэлт гүйцэтгэдэг. Нэг ачааллын үр дүнг нөгөөгийн оронд тавивал profile, event log, каталогт буруу сонголт хийх эрсдэлтэй.

Монгол дахь хэрэглэгчийн мэдрэх нийт хугацаанд өгөгдлийн сангийн саатлаас гадна хэрэглээний серверийн байрлал, сүлжээний зам, асуулгын боловсруулалт нөлөөлнө. Ижил хүсэлт, өгөгдлийн хэмжээ, нийцтэй байдлын тохиргоо, төсөвтэй хувилбаруудын үр дүн л архитектурын шийдвэрт шууд харьцуулагдана. Хурдны тоог тухайн туршилтын нөхцөлөөс салгахгүй байх нь чухал.

Төлбөрт хүсэлтээс гадна юу ордог вэ?

MongoDB Atlas-ийн үнийн мэдээлэлд зориулалтын cluster цагийн тарифтай, өртөг нь түвшин, cloud нийлүүлэгч, бүс, өгөгдөл ба индексийн хадгалалт, гадагш дамжуулах урсгал, нөөцлөлтөөс хамаардгийг тайлбарласан. Байнгын ачаалалтай үйлчилгээ зориулалтын нөөцөө тогтвортой ашиглаж болно. Харин сул цагт ч ажиллаж буй cluster-ийн төлбөр үргэлжлэх тул зөвхөн сарын хүсэлтийн тоогоор энэ загварыг тооцох нь дутуу.

Amazon DynamoDB-ийн үнийн хуудсанд on-demand горим унших, бичих хэрэглэсэн хүсэлтээр, provisioned горим захиалсан унших, бичих хүчин чадлаар тооцогддог бөгөөд provisioned хүчин чадалтай Standard хүснэгтийн үнэгүй түвшинд 25 GB хадгалалт багтдаг. Хэлбэлзэлтэй ачаалалд on-demand нь хүчин чадлыг урьдчилан тааруулах ажлыг багасгана; тогтвортой ачаалалд provisioned горимыг төсөвтэй харьцуулах боломжтой. Хоёрдогч индекс, хадгалалт, нөөцлөлт болон бүс хоорондын ажиллагаа нэмэгдэхэд нийт төлбөр өөрчлөгдөнө.

Каталогийн шинэ шүүлтүүрээс үүдэх индексийн зардал болон event log-ийн тасралтгүй бичилт нэг ижил үнийн харьцуулалт өгөхгүй. Profile-ийн түлхүүрт уншилт давамгайлдаг хувилбарт ч оргил ачаалал, бичлэгийн хэмжээ, шаардлагатай нөөцлөлтийг хамтад нь тооцно. Төлбөрийн загвар өгөгдлийн загвараас тусдаа шийдвэр биш: асуулгыг гүйцэтгэхээр сонгосон бүтэц өөрөө хэрэглэгдэх нөөцийг тодорхойлдог.

Cloud сонголт ба шилжих өртөг

Atlas-ийг өөр өөр cloud нийлүүлэгч дээр байрлуулах сонголт бий. Гэхдээ ажиллаж буй өгөгдлийг өөр бүс эсвэл нийлүүлэгч рүү шилжүүлэхэд дамжуулалт, сүлжээний тохиргоо, ажиллагааны ажил гарна. DynamoDB нь AWS-ийн үйлчилгээ тул түүний түлхүүр, индекс, хүсэлтийн API-д нягт тааруулсан програмыг өөр өгөгдлийн сан руу шилжүүлэхэд асуулгын код болон хандалтын загварыг дахин боловсруулах шаардлага үүсэж болно. Энэ нь үйлчилгээний нэрээр бус, програм өгөгдөлд хэрхэн ханддагаар хэмжигдэх хамаарал юм.

Шүүлтүүр нь бүтээгдэхүүнтэйгээ хамт хувьсдаг каталогт Atlas-ийн уян асуулга илүү үнэ цэнтэй; тогтсон түлхүүрээр ихэвчлэн ажилладаг event log эсвэл profile-д DynamoDB-ийн загвар илүү энгийн байж болно. Эцсийн сонголтод сарын үндсэн төлбөрөөс гадна шинэ асуулга нэмэхэд индекс, бичилт, өгөгдөл дамжуулалт болон програмын кодод гарах өөрчлөлтийг хамтад нь авч үзнэ.

Мөн уншаарай:

• PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө
• Supabase эсвэл Firebase: үнэгүй quota өсөхөд өөр төрлийн төлбөр болдог
• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө