Мэдээж чатуудыг хадгалах шаардлагатай. Үүний тулд өгөгдлийн сан шаардлагатай ба хамгийн эхэнд санаанд орсон нь PostgreSQL байсан. Ер нь би шинэ юм хийхэд байнга л ашигладаг database-н нэг нь. Яагаад анх сонгосон бэ гэвэл:

  • Ecosystem: PostgreSQL олон жилийн турш хөгжиж ирсэн. Community support маш сайн, documentation сайн бас олон extension-үүд байдаг.
  • Data Integrity: PostgreSQL нь **ACID compliance-**тай тул өгөгдлийн найдвартай байдлыг хангана.
  • Powerful Querying: SQL engine нь маш сайн, complex query, indexing стратеги болон **full-text search-**ийг дэмждэг.
  • Flexibility: JSON/JSONB, custom data type-үүд болон PL/pgSQL гэх мэт процедурын хэлнүүдийг дэмждэг ба шаардлагатай бол ашиглахад тохиромжтой.

Анхны бүтэц

Эхний байдлаар chat_room хүснэгтийг үүсгэж, chat-ийг хадгалахдаа дараах бүтцээр хадгална гэж бодсон:

CREATE TABLE chat_room (
  id SERIAL PRIMARY KEY,
  room_id INT NOT NULL,
  user_id INT NOT NULL,
  chat TEXT NOT NULL
);

Энэ нь хэрэглэгч болон өрөөний тоо бага бол асуудалгүй ажиллана. Гэвч хэмжээ илүү ихээр томрох үед хурд, scalability асуудал үүсэх боломжтой.

Scale хийх асуудал

Chat -нь олон хүн байх тусам маш хурдтай ихсэх боломжтой. Тиймээс room_id дээр index хийсэн ч гэсэн өгөгдлийн хэмжээ өсөхийн хэрээр хурд буурах эрсдэлтэй. Учир нь table-н хэмжээ асар том болно.

Chat-ийн гол үйлдлүүд бол тухайн өрөөний мессежүүдийг унших, бичих. Эдгээр нь хурдан байх ёстой. Өгөгдлийг хэсэг хэсгээр нь багцалж, хамт байлгах нь read, write-н хурдыг нэмэгдүүлэх боломжтой.

Гэхдээ PostgreSQL-ийн хувьд бүх chat мессежүүд нэг хүснэгтэд хадгалагдах тул өгөгдөл тархаж, томрох тусам хайлт хийх, нэмэх хурд удааширна.

Partition

Жижиг болгож багцлах нь чухал ба өрөө болон хугацаагаар нь нэг бүлэг болговол read, write хийх нь хамаагүй хурдан, мөн нэг хүснэгт хэт их томрохоос сэргийлэх боломжтой. PostgreSQL нь partition дэмждэг ч 1-л leader-тэй учир цаашдаа scale хийхэд асуудалтай гэж харсан.

Тиймээс илүү тохиромжтой шийдэл хайж байхдаа ScyllaDB-г олсон.

Яагаад ScyllaDB?

ScyllaDB бол NoSQL өгөгдлийн сан бөгөөд high performance and scalability-д зориулагдсан. Гол давуу талууд:

  • Автомат data partitioning: Өгөгдлийг **distributed cluster-**т автоматаар хуваарилж, ачааллыг тэнцвэржүүлнэ.
  • Хурд: Маш хурдан унших, бичих үйлдэл хийх боломжтой. Chat application-д энэ нь маш чухал.
  • Scalability: Database cluster-д шинэ node нэмэхэд төвөггүй.

Шилжилт хийх нь

ScyllaDB ашиглан өгөгдлөө шинэ бүтэцтэй хадгалахаар шийдсэн. Chat мессежүүдийг өрөө болон хугацаагаар хувааж хадгалвал илүү тохиромжтой. Ингэснээр тухайн өрөө болон хугацааны бүх мессежүүд багцлагдан, хайлт илүү хурдан болож боломжтой

ScyllaDB дээрх хүснэгтийн жишээ:

CREATE TABLE chat_messages (
  room_id INT,
  bucket INT,
  message_id bigint,
  user_id INT,
  chat TEXT,
  PRIMARY KEY ((room_id, bucket), message_id)
) WITH CLUSTERING ORDER BY (message_id DESC)

Энд (room_id, bucket) нь composite partition key бөгөөд өгөгдлийг багцлахад тусална. Ингэснээр read/write үйлдлүүд илүү хурдан болж, өгөгдлийн сан томрох үед ч тогтвортой ажиллагааг хангана.

Давуу талууд

ScyllaDB рүү шилжих нь дараах давуу талыг өгсөн:

  • Improved Performance: Илүү олон хэрэглэгчийн ачааллыг асуудалгүй дааж чадна.
  • Scalability нэмэгдсэн: Шинэ node нэмэх нь амархан тул систем ачааллыг төвөггүй зохицуулна.
  • Easier Data management: Time-based partitioning ашигласнаар хуучин өгөгдлийг архивлах эсвэл устгахад илүү хялбар болсон.

Дүгнэлт

Шинэ зүйлийг бүтээх нь зөв технологи сонгох, түүнийг зөв ашиглах нь хамгийн чухал зүйлсийн нэг билээ. PostgreSQL маш сайн өгөгдлийн сан боловч их ачаалалтай chat application-д зориулж ScyllaDB-ийг сонгох нь илүү тохиромжтой байсан.

Өгөгдлийн сангийн хувьд нэг л зөв шийдэл гэж байхгүй. Гол нь таны application-ийн шаардлагад тохирсон технологийг сонгох нь чухал. Миний хувьд зарим хэсгийг нь ScyllaDB рүү шилжих нь performance, scalability -г илүү нэмэгдүүлсэн.

Ирээдүйд ScyllaDB-ийн distributed architecture талаар илүү дэлгэрэнгүй бичих болно.