เมื่อใดควรใช้ document database

แนวคิด NoSQL

Miriam Antona

Software engineer

กรณีที่เหมาะสม

แคตาล็อก
- เว็บไซต์/แอปพลิเคชัน e-commerce เก็บข้อมูลสินค้า
- แอตทริบิวต์ของสินค้าแต่ละรายการแตกต่างกัน
- ฝังข้อมูลที่เกี่ยวข้องไว้ด้วยกัน

ภาพเสื้อ

{
  "product_id": 879,
  "name": "Fashion shirt",
  "category": {
    "category_id": 15,
    "name": "Tops & t-shirts",
    "type": "Shirt"
  }
}

กรณีที่เหมาะสม

การบันทึก event
- ประเภทของ event:
  - การล็อกอินของผู้ใช้
  - การซื้อสินค้า
  - ข้อผิดพลาด
  - ...
- การแบ่ง shard ตาม:
  - เวลา
  - ประเภทของ event
  - ...

ภาพ log ของ event

{
  "type": "info",
  "message": "user_logged",
  "user_id": 551,
  ...
}

กรณีที่เหมาะสม

โปรไฟล์ผู้ใช้

{
  "user_id": 512,
  "name": "Carol",
  "last_name": "Harper",
  "email": "[email protected]",
  "address": {
    "street": "123 Sesame Street",
    "city": "New York City",
    "state": "New York"
  },
  ...
}

ภาพโปรไฟล์ผู้ใช้

ข้อมูลอาจแตกต่างกันในแต่ละผู้ใช้
ความยืดหยุ่นของ document

กรณีที่เหมาะสม

ระบบจัดการเนื้อหา
- บล็อก, แพลตฟอร์มวิดีโอ ฯลฯ
- เนื้อหาของผู้ใช้
  - คอมเมนต์
  - รูปภาพ
  - วิดีโอ
  - ...

ภาพบล็อก

{
  "id": 458,
  "url": "myblog/datazy.com",
  "title": "How to write a blog entry at Datazy",
  "tags": [
    "Datazy",
    "Blog"
  ],
  "last10comments": [
    { "name": "Eliza", "comment": "Great!" },
    { "name": "Eric", "comment": "Thank you!"}
  ]...
}

กรณีที่เหมาะสม

การวิเคราะห์แบบ real-time
- จำนวนการเข้าชมหน้า, ผู้เยี่ยมชมเฉพาะ...
- จัดเก็บข้อมูลได้ง่าย

ภาพการวิเคราะห์แบบ real-time

{
  "_id": "1000241",
  "hour": "Sat Jun 12 2021 16:40:00 GMT+0200 (EST)",
  "site": "datazy",
  "uniques": 5,
  "pageviews": 15,
  ...
}

กรณีที่ไม่เหมาะสม

ข้อมูลที่มีโครงสร้างตายตัวมาก
ข้อมูลที่สม่ำเสมอเสมอ

มาฝึกกันเถอะ!

แนวคิด NoSQL