Redis эсвэл Memcached: ижил GET/SET хурдтай ч өгөгдлийн насжилт шийднэ

Үндсэн өгөгдлөөс дахин бүтээж болох query cache-д Memcached хангалттай байж болно. Харин session эсвэл бодит цагийн төлөвийг тасалдлын дараа сэргээх, хуулбарлах, бүтэцтэй нь боловсруулах хэрэгтэй бол Redis илүү тохирно. Ижил GET/SET ажиллагааны хурд ойролцоо гарлаа ч өгөгдөл алга болоход юу болох нь сонголтыг өөрчилдөг.

Хурдны зөрүүг шийдвэрийн үндэс болгохын өмнө хэмжилтийн нөхцөлийг тэнцүүлэх шаардлагатай. Redis-ийн benchmark заавар хоёр системд ижил GET/SET ажиллагаа, ойролцоо холболтын тоо болон хүсэлтийг бөөгнүүлэх аргыг хэрэглэвэл харьцуулалт утгатай болохыг тайлбарладаг. Тийм нөхцөлд ч GET хариу авах хугацаа нь кэш алдагдсаны дараах сэргэлт, санах ой дүүрэх үеийн зан төлөвийг хэмжихгүй.

GET/SET хэмжилт яг юуг харуулдаг вэ

Нийтлэгдсэн нэг хэмжилт нь ачааллын нөхцөл хэр чухлыг харуулна. Linux Plumbers Conference-д танилцуулсан туршилтын тохиргоонд Redis ба Memcached-ийг SET:GET-ийн 1:10 харьцаа, дунджаар 64 байтын утга, урьдчилан дүүргэсэн кэшийн 95 хувийн hit rate, тус бүр хоёр минутын таван давталтаар шалгаж, instance бүрийн p99 хоцролтыг нэг миллисекундээс доош байлгах босго тавьсан. Энэ нь хоосон кэш эсвэл session сэргээх ажиллагааны хэмжилт биш.

Туршилтын зорилго нь хоёр бүтээгдэхүүний бүх хэрэглээнд хүчинтэй хурдны ялагчийг тодруулах бус, санах ойн хуудасны тохиргооны нөлөөг хэмжих байв. Redis-ийн дискэн хадгалалтыг ашиглаагүй бөгөөд client-ийн тоо, pipeline дахь зэрэг хүсэлтийг платформ бүрд тусад нь тохируулсан. Тиймээс нийт throughput-ийг дангаар нь авч, хадгалалт идэвхтэй үйлдвэрлэлийн орчинд ижил үр дүн гарна гэж үзэх үндэсгүй.

Өөрийн workload-д GET ба SET-ийн эзлэх хувь, утгын хэмжээ, түлхүүрийн тархалт, hit rate, холболт болон pipeline-ийг ижил байлгаж байж серверүүдийг харьцуулна. Нэг секундэд боловсруулсан хүсэлтийн тооны хажууд p99-ийг харах нь чухал: хүсэлтийн дийлэнх нь хурдан байсан ч удаан хариулсан хэсэг үйлчилгээний хоцролтын босгыг давж болно. Хэрэв хэрэглээнд кэш байнга дүүрдэг бол түлхүүр хөөгдөх үеийг хэмжилтэд оруулна.

Query cache-д Memcached хэзээ хүрэлцэх вэ

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

Алдагдлын бодит үнэ нь тухайн хариуг дахин гаргах хугацаа болон үндсэн сангийн нэмэлт ачаалал юм. Жишээ нь, нөхцөлт байдлаар бүтээгдэхүүний жагсаалтын query-ийн хариуг хадгалж байгаа бол хугацаа дууссан түлхүүрийг дахин тооцож болно. Харин олон түлхүүр зэрэг алга болж, үндсэн сан давхар хүсэлтийг даахгүй бол кэшийн miss нь хэрэглэгчийн хүлээх хугацааг өсгөнө.

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

Session ба бодит цагийн төлөвт Redis юу нэмдэг вэ

Session-д байгаа мэдээллийг өөр газраас сэргээх боломжгүй бол хадгалалтын бодлого хурднаас түрүүлж тавигдана. Redis-ийн албан танилцуулга дискэнд үе үе snapshot хийх, бичилтийг логт нэмэх, асинхрон хуулбарлалт хийх сонголт болон hash, list, set, sorted set, stream зэрэг өгөгдлийн бүтцийг тайлбарладаг. Эдгээрийг хэрэглэх эсэх нь тухайн төлөвийг хэр удаан хадгалах, тасалдлын дараа хэрхэн сэргээх шаардлагаас хамаарна.

Нэвтрэлтийн богино хугацааны туслах мэдээллийг шинээр үүсгэж болдог session бол энгийн кэшийн шинжтэй. Харин сагсны төлөв эсвэл дуусаагүй үйлдлийн явц өөр эх сурвалжид байхгүй бол алдаж болох өөрчлөлтийн хэмжээг тогтоох хэрэгтэй. Snapshot нь авсан агшнаасаа хойших бичилтийг дангаараа хадгалахгүй; бичилтийн логийн дискэнд баталгаажих бодлого мөн сэргээх үр дүнд нөлөөлнө. Асинхрон хуулбарлалттай үед хамгийн сүүлийн өөрчлөлт хуулбарт хараахан хүрээгүй байх боломжтой.

Бодит цагийн өгөгдөлд сервер талын ажиллагаа бас ялгаа гаргана. Нэг бүхэл утгыг хадгалаад буцааж авах бол GET/SET загвар хүрэлцэж болно. Харин олон талбартай төлөвийн зөвхөн нэг хэсгийг өөрчлөх, оноогоор эрэмбэлэх эсвэл үйл явдлыг дарааллаар нь боловсруулах шаардлагатай бол Redis-ийн өгөгдлийн бүтэц тухайн ажиллагааг илүү шууд илэрхийлнэ. Ийм шаардлагагүй үед нэмэлт боломж нь өөрөө хурдны давуу тал болдоггүй.

TTL, eviction ба дахин асалт

TTL, eviction, дискэн хадгалалт гурвын үүрэг өөр. TTL нь түлхүүр хэзээ хүчингүй болохыг, eviction нь санах ойн зай хүрэлцэхгүй үед ямар түлхүүрийг зайлуулахыг шийднэ. Дискэн хадгалалт нь процесс эсвэл машин тасалдсаны дараа төлөвийг сэргээхтэй холбоотой. Session-ийн хугацааг зөв тавьсан ч санах ойн хязгаарт хүрээд хэрэгтэй түлхүүр хөөгдвөл хэрэглэгчийн төлөв хугацаанаасаа өмнө алга болно.

Memcached дахин асах бүрт заавал хоосон кэштэй эхэлдэггүй. Memcached-ийн warm restart баримт тохирсон орчинд цэвэр унтраалтын дараа кэшийн өгөгдлийг сэргээх боломжийг тайлбарлахын зэрэгцээ үүнийг гэнэтийн уналтад тэсвэртэй хадгалалт гэж үзэхгүйг анхааруулдаг. Дахин асах хооронд ирсэн шинэчлэлтүүд алдагдаж болох тул энэ боломжийг session-ийн баталгаатай хадгалалттай адилтгаж болохгүй.

Өгөгдлийн насжилтыг зөвхөн TTL-ийн тоогоор илэрхийлэх боломжгүй. Түлхүүр хугацаанаасаа өмнө хөөгдөх эсэх, зангилаа унтарвал ямар эх сурвалжаас эргэж бүрдэх, сэргээх хооронд хүсэлтүүд хаашаа очих нь нэг шийдвэрийн хэсэг. Дахин тооцож болох query-ийн хариу болон өөр газарт байхгүй хэрэглэгчийн төлөв ижил хугацаатай түлхүүр байсан ч алдагдлын үнэ нь өөр.

Олон цөм ба p99-ийн шаардлага

Ачаалал өсөхөд thread-ийн загварыг нийт throughput-тэй хамт харна. Memcached олон thread ашигладаг бол Redis-ийн командын гүйцэтгэл үндсэндээ нэг thread-д төвлөрдөг; Redis-ийг олон цөмд тэлэхэд олон instance болон түлхүүрийн хуваарилалт хэрэгтэй байж болно. Гэхдээ thread-ийн тоо дангаараа ялагчийг тогтоохгүй. Client ачаалал үүсгэгч эсвэл сүлжээ түрүүлж хязгаарт хүрвэл серверт нэмсэн хүчин чадал хэмжилтэд бүрэн харагдахгүй.

p99-ийн босгыг үйлчилгээний бодит замд тавих нь илүү хэрэгтэй. Ердийн cache hit, хугацаа нь дууссан түлхүүр, санах ой дүүрсэн үе, дахин асалтын дараах дүүргэлт өөр өөр хоцролт өгнө. Хадгалалт идэвхтэй Redis-ийг хадгалалтгүй Memcached-тэй хэмжвэл хоёр өөр ажиллагааны бодлогыг хамтад нь харьцуулж буй хэрэг; цэвэр GET/SET чадварыг ялгахын тулд тохиргооны энэ зөрүүг тусад нь тэмдэглэнэ.

Ачааллаас эхэлсэн сонголт

Эхлээд кэшийн түлхүүр алга болоход хариуг дахин бүтээж чадах эсэхийг шийднэ. Чадна, мөн дахин тооцох үеийн ачааллыг үндсэн сан даана гэвэл Memcached-ийг энгийн query cache-ийн хувилбар болгон үнэлэх үндэслэлтэй. Төлөвийг тасалдлын дараа сэргээх, өөр зангилаанд хуулбарлах эсвэл бүтцийн хэсэгт сервер талд ажиллагаа хийх шаардлагатай бол Redis-ийн холбогдох боломж, тэдгээрийн тохиргооны зардлыг хамт үнэлнэ.

Дараа нь сонгосон ажиллагааны бодлогодоо ижил workload ажиллуулж, throughput болон p99-ийг кэшийн hit, miss, дүүргэлтийн нөхцөлтэй нь хамт харьцуулна. GET/SET-ийн хурд ойролцоо үед шийдвэрийг ихэвчлэн түлхүүр алга болсны дараах ажил тодруулдаг: дахин тооцох уу, дискнээс сэргээх үү, эсвэл хуулбараас үргэлжлүүлэх үү.

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

• PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө
• OpenAI эсвэл Claude prompt cache: буруу хил latency-г өсгөнө
• Neon эсвэл Supabase: ижил Postgres-ийн clone хийх арга 23 дахин зөржээ