การเพิ่มประสิทธิภาพการสืบค้น SQLAlchemy: การควบคุม Lazy Loading เทียบกับ Eager Loading

SQLAlchemy เป็นชุดเครื่องมือ SQL Python และ Object Relational Mapper (ORM) ที่มีประสิทธิภาพ ซึ่งช่วยลดความซับซ้อนของการโต้ตอบกับฐานข้อมูล แง่มุมที่สำคัญของการเขียนแอปพลิเคชัน SQLAlchemy ที่มีประสิทธิภาพคือการทำความเข้าใจและการใช้กลยุทธ์การโหลดอย่างมีประสิทธิภาพ บทความนี้เจาะลึกเทคนิคพื้นฐานสองอย่าง: lazy loading และ eager loading สำรวจจุดแข็ง จุดอ่อน และการใช้งานจริง

ทำความเข้าใจปัญหา N+1

ก่อนที่จะเจาะลึก lazy และ eager loading สิ่งสำคัญคือต้องเข้าใจปัญหา N+1 ซึ่งเป็นคอขวดด้านประสิทธิภาพทั่วไปในแอปพลิเคชันที่ใช้ ORM ลองนึกภาพว่าคุณต้องดึงรายชื่อผู้เขียนจากฐานข้อมูล จากนั้นดึงหนังสือที่เกี่ยวข้องสำหรับผู้เขียนแต่ละคน แนวทางที่เรียบง่ายอาจเกี่ยวข้องกับ:

1. ออกคำสั่งสืบค้นหนึ่งคำสั่งเพื่อดึงผู้เขียนทั้งหมด (1 คำสั่งสืบค้น)
2. วนซ้ำในรายชื่อผู้เขียนและออกคำสั่งสืบค้นแยกต่างหากสำหรับผู้เขียนแต่ละคนเพื่อดึงหนังสือของพวกเขา (N คำสั่งสืบค้น โดยที่ N คือจำนวนผู้เขียน)

ส่งผลให้มีคำสั่งสืบค้นทั้งหมด N+1 คำสั่ง เมื่อจำนวนผู้เขียน (N) เพิ่มขึ้น จำนวนคำสั่งสืบค้นจะเพิ่มขึ้นเป็นเส้นตรง ซึ่งส่งผลกระทบอย่างมากต่อประสิทธิภาพ ปัญหา N+1 เป็นปัญหาอย่างยิ่งเมื่อจัดการกับชุดข้อมูลขนาดใหญ่หรือความสัมพันธ์ที่ซับซ้อน

Lazy Loading: การดึงข้อมูลตามความต้องการ

Lazy loading หรือที่เรียกว่า deferred loading เป็นลักษณะการทำงานเริ่มต้นใน SQLAlchemy ด้วย lazy loading ข้อมูลที่เกี่ยวข้องจะไม่ถูกดึงจากฐานข้อมูลจนกว่าจะมีการเข้าถึงอย่างชัดเจน ในตัวอย่างผู้เขียน-หนังสือของเรา เมื่อคุณดึงอ็อบเจ็กต์ผู้เขียน แอตทริบิวต์ `books` (โดยสมมติว่ามีการกำหนดความสัมพันธ์ระหว่างผู้เขียนและหนังสือ) จะไม่ถูกเติมทันที แต่ SQLAlchemy จะสร้าง "lazy loader" ที่ดึงหนังสือเมื่อคุณเข้าถึงแอตทริบิวต์ `author.books` เท่านั้น

ตัวอย่าง:

from sqlalchemy import create_engine, Column, Integer, String, ForeignKey
from sqlalchemy.orm import relationship, sessionmaker
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class Author(Base):
    __tablename__ = 'authors'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    books = relationship("Book", back_populates="author")

class Book(Base):
    __tablename__ = 'books'
    id = Column(Integer, primary_key=True)
    title = Column(String)
    author_id = Column(Integer, ForeignKey('authors.id'))
    author = relationship("Author", back_populates="books")

engine = create_engine('sqlite:///:memory:') # แทนที่ด้วย URL ฐานข้อมูลของคุณ
Base.metadata.create_all(engine)

Session = sessionmaker(bind=engine)
session = Session()

# สร้างผู้เขียนและหนังสือบางส่วน
author1 = Author(name='Jane Austen')
author2 = Author(name='Charles Dickens')
book1 = Book(title='Pride and Prejudice', author=author1)
book2 = Book(title='Sense and Sensibility', author=author1)
book3 = Book(title='Oliver Twist', author=author2)

session.add_all([author1, author2, book1, book2, book3])
session.commit()

# Lazy loading ในการดำเนินการ
authors = session.query(Author).all()

for author in authors:
    print(f"Author: {author.name}")
    print(f"Books: {author.books}") # สิ่งนี้กระตุ้นให้เกิดคำสั่งสืบค้นแยกต่างหากสำหรับผู้เขียนแต่ละคน
    for book in author.books:
        print(f"  - {book.title}")

ในตัวอย่างนี้ การเข้าถึง `author.books` ภายในลูปจะกระตุ้นให้เกิดคำสั่งสืบค้นแยกต่างหากสำหรับผู้เขียนแต่ละคน ซึ่งส่งผลให้เกิดปัญหา N+1

ข้อดีของ Lazy Loading:

• ลดเวลาโหลดเริ่มต้น: เฉพาะข้อมูลที่จำเป็นอย่างชัดเจนเท่านั้นที่โหลดในตอนแรก ซึ่งนำไปสู่เวลาตอบสนองที่เร็วขึ้นสำหรับคำสั่งสืบค้นเริ่มต้น
• ลดการใช้หน่วยความจำ: ข้อมูลที่ไม่จำเป็นจะไม่ถูกโหลดลงในหน่วยความจำ ซึ่งอาจเป็นประโยชน์เมื่อจัดการกับชุดข้อมูลขนาดใหญ่
• เหมาะสำหรับการเข้าถึงที่ไม่บ่อยนัก: หากมีการเข้าถึงข้อมูลที่เกี่ยวข้องไม่บ่อยนัก lazy loading จะหลีกเลี่ยงการเดินทางไปกลับฐานข้อมูลโดยไม่จำเป็น

ข้อเสียของ Lazy Loading:

• ปัญหา N+1: ศักยภาพสำหรับปัญหา N+1 สามารถลดประสิทธิภาพลงอย่างมาก โดยเฉพาะอย่างยิ่งเมื่อวนซ้ำในคอลเล็กชันและเข้าถึงข้อมูลที่เกี่ยวข้องสำหรับแต่ละรายการ
• เพิ่มการเดินทางไปกลับฐานข้อมูล: คำสั่งสืบค้นหลายรายการสามารถนำไปสู่เวลาแฝงที่เพิ่มขึ้น โดยเฉพาะอย่างยิ่งในระบบกระจายหรือเมื่อเซิร์ฟเวอร์ฐานข้อมูลอยู่ห่างไกล ลองนึกภาพการเข้าถึงเซิร์ฟเวอร์แอปพลิเคชันในยุโรปจากออสเตรเลียและการเข้าถึงฐานข้อมูลในสหรัฐอเมริกา
• ศักยภาพสำหรับคำสั่งสืบค้นที่ไม่คาดคิด: อาจเป็นเรื่องยากที่จะคาดการณ์ว่าเมื่อใดที่ lazy loading จะกระตุ้นให้เกิดคำสั่งสืบค้นเพิ่มเติม ทำให้การแก้ไขจุดบกพร่องด้านประสิทธิภาพมีความท้าทายมากขึ้น

Eager Loading: การดึงข้อมูลเชิงรุก

Eager loading ตรงกันข้ามกับ lazy loading จะดึงข้อมูลที่เกี่ยวข้องล่วงหน้า พร้อมกับคำสั่งสืบค้นเริ่มต้น ซึ่งจะช่วยลดปัญหา N+1 โดยการลดจำนวนการเดินทางไปกลับฐานข้อมูล SQLAlchemy มีหลายวิธีในการใช้งาน eager loading โดยส่วนใหญ่ใช้ตัวเลือก `joinedload`, `subqueryload` และ `selectinload`

1. Joined Loading: แนวทางคลาสสิก

Joined loading ใช้ SQL JOIN เพื่อดึงข้อมูลที่เกี่ยวข้องในคำสั่งสืบค้นเดียว โดยทั่วไปแล้วนี่เป็นแนวทางที่มีประสิทธิภาพมากที่สุดเมื่อจัดการกับความสัมพันธ์แบบหนึ่งต่อหนึ่งหรือหนึ่งต่อกลุ่มและข้อมูลที่เกี่ยวข้องจำนวนค่อนข้างน้อย

ตัวอย่าง:

from sqlalchemy.orm import joinedload

authors = session.query(Author).options(joinedload(Author.books)).all()

for author in authors:
    print(f"Author: {author.name}")
    for book in author.books:
        print(f"  - {book.title}")

ในตัวอย่างนี้ `joinedload(Author.books)` บอก SQLAlchemy ให้ดึงหนังสือของผู้เขียนในคำสั่งสืบค้นเดียวกันกับตัวผู้เขียนเอง หลีกเลี่ยงปัญหา N+1 SQL ที่สร้างขึ้นจะมี JOIN ระหว่างตาราง `authors` และ `books`

2. Subquery Loading: ทางเลือกที่มีประสิทธิภาพ

Subquery loading ดึงข้อมูลที่เกี่ยวข้องโดยใช้ subquery แยกต่างหาก แนวทางนี้อาจเป็นประโยชน์เมื่อจัดการกับข้อมูลที่เกี่ยวข้องจำนวนมากหรือความสัมพันธ์ที่ซับซ้อนที่คำสั่งสืบค้น JOIN เดียวอาจไม่มีประสิทธิภาพ แทนที่จะเป็น JOIN ขนาดใหญ่เพียงครั้งเดียว SQLAlchemy จะดำเนินการคำสั่งสืบค้นเริ่มต้น จากนั้นจึงดำเนินการคำสั่งสืบค้นแยกต่างหาก (subquery) เพื่อดึงข้อมูลที่เกี่ยวข้อง จากนั้นผลลัพธ์จะถูกรวมเข้าด้วยกันในหน่วยความจำ

ตัวอย่าง:

from sqlalchemy.orm import subqueryload

authors = session.query(Author).options(subqueryload(Author.books)).all()

for author in authors:
    print(f"Author: {author.name}")
    for book in author.books:
        print(f"  - {book.title}")

Subquery loading หลีกเลี่ยงข้อจำกัดของ JOIN เช่น ผลิตภัณฑ์คาร์ทีเซียนที่อาจเกิดขึ้น แต่อาจมีประสิทธิภาพน้อยกว่า joined loading สำหรับความสัมพันธ์ง่ายๆ ที่มีข้อมูลที่เกี่ยวข้องจำนวนน้อย มีประโยชน์อย่างยิ่งเมื่อคุณมีหลายระดับของความสัมพันธ์ที่จะโหลด ป้องกัน JOIN ที่มากเกินไป

3. Selectin Loading: โซลูชันที่ทันสมัย

Selectin loading ซึ่งเปิดตัวใน SQLAlchemy 1.4 เป็นทางเลือกที่มีประสิทธิภาพมากกว่า subquery loading สำหรับความสัมพันธ์แบบหนึ่งต่อกลุ่ม สร้างคำสั่งสืบค้น SELECT...IN ดึงข้อมูลที่เกี่ยวข้องในคำสั่งสืบค้นเดียวโดยใช้คีย์หลักของอ็อบเจ็กต์หลัก ซึ่งหลีกเลี่ยงปัญหาด้านประสิทธิภาพที่อาจเกิดขึ้นของ subquery loading โดยเฉพาะอย่างยิ่งเมื่อจัดการกับอ็อบเจ็กต์หลักจำนวนมาก

ตัวอย่าง:

from sqlalchemy.orm import selectinload

authors = session.query(Author).options(selectinload(Author.books)).all()

for author in authors:
    print(f"Author: {author.name}")
    for book in author.books:
        print(f"  - {book.title}")

Selectin loading มักเป็นกลยุทธ์ eager loading ที่ต้องการสำหรับความสัมพันธ์แบบหนึ่งต่อกลุ่ม เนื่องจากประสิทธิภาพและความเรียบง่าย โดยทั่วไปจะเร็วกว่า subquery loading และหลีกเลี่ยงปัญหาที่อาจเกิดขึ้นจาก JOIN ขนาดใหญ่มาก

ข้อดีของ Eager Loading:

• ลดปัญหา N+1: ลดจำนวนการเดินทางไปกลับฐานข้อมูล ปรับปรุงประสิทธิภาพอย่างมีนัยสำคัญ
• ปรับปรุงประสิทธิภาพ: การดึงข้อมูลที่เกี่ยวข้องล่วงหน้าอาจมีประสิทธิภาพมากกว่า lazy loading โดยเฉพาะอย่างยิ่งเมื่อมีการเข้าถึงข้อมูลที่เกี่ยวข้องบ่อยครั้ง
• การดำเนินการคำสั่งสืบค้นที่คาดการณ์ได้: ทำให้ง่ายต่อการทำความเข้าใจและเพิ่มประสิทธิภาพประสิทธิภาพของคำสั่งสืบค้น

ข้อเสียของ Eager Loading:

• เพิ่มเวลาโหลดเริ่มต้น: การโหลดข้อมูลที่เกี่ยวข้องทั้งหมดล่วงหน้าอาจเพิ่มเวลาโหลดเริ่มต้น โดยเฉพาะอย่างยิ่งหากข้อมูลบางส่วนไม่จำเป็นต้องใช้จริง
• การใช้หน่วยความจำที่สูงขึ้น: การโหลดข้อมูลที่ไม่จำเป็นลงในหน่วยความจำสามารถเพิ่มการใช้หน่วยความจำ ซึ่งอาจส่งผลกระทบต่อประสิทธิภาพ
• ศักยภาพในการดึงข้อมูลมากเกินไป: หากต้องการเพียงส่วนเล็กๆ ของข้อมูลที่เกี่ยวข้อง eager loading อาจส่งผลให้มีการดึงข้อมูลมากเกินไป ทำให้สิ้นเปลืองทรัพยากร

การเลือกกลยุทธ์การโหลดที่เหมาะสม

ทางเลือกระหว่าง lazy loading และ eager loading ขึ้นอยู่กับข้อกำหนดเฉพาะของแอปพลิเคชันและรูปแบบการเข้าถึงข้อมูล นี่คือคู่มือการตัดสินใจ:

เมื่อใดควรใช้ Lazy Loading:

• มีการเข้าถึงข้อมูลที่เกี่ยวข้องไม่บ่อยนัก หากคุณต้องการข้อมูลที่เกี่ยวข้องในเปอร์เซ็นต์เล็กน้อยเท่านั้น lazy loading อาจมีประสิทธิภาพมากกว่า
• เวลาโหลดเริ่มต้นมีความสำคัญอย่างยิ่ง หากคุณต้องการลดเวลาโหลดเริ่มต้นให้เหลือน้อยที่สุด lazy loading อาจเป็นตัวเลือกที่ดี โดยเลื่อนการโหลดข้อมูลที่เกี่ยวข้องออกไปจนกว่าจะจำเป็น
• การใช้หน่วยความจำเป็นข้อกังวลหลัก หากคุณกำลังจัดการกับชุดข้อมูลขนาดใหญ่และหน่วยความจำมีจำกัด lazy loading สามารถช่วยลดรอยเท้าหน่วยความจำได้

เมื่อใดควรใช้ Eager Loading:

• มีการเข้าถึงข้อมูลที่เกี่ยวข้องบ่อยครั้ง หากคุณรู้ว่าคุณจะต้องใช้ข้อมูลที่เกี่ยวข้องในกรณีส่วนใหญ่ eager loading สามารถลดปัญหา N+1 และปรับปรุงประสิทธิภาพโดยรวมได้
• ประสิทธิภาพมีความสำคัญอย่างยิ่ง หากประสิทธิภาพเป็นสิ่งสำคัญอันดับแรก eager loading สามารถลดจำนวนการเดินทางไปกลับฐานข้อมูลได้อย่างมาก
• คุณกำลังประสบปัญหา N+1 หากคุณเห็นคำสั่งสืบค้นที่คล้ายกันจำนวนมากถูกดำเนินการ eager loading สามารถใช้เพื่อรวมคำสั่งสืบค้นเหล่านั้นเป็นคำสั่งสืบค้นเดียวที่มีประสิทธิภาพมากขึ้นได้

คำแนะนำกลยุทธ์ Eager Loading เฉพาะ:

• Joined Loading: ใช้สำหรับความสัมพันธ์แบบหนึ่งต่อหนึ่งหรือหนึ่งต่อกลุ่มที่มีข้อมูลที่เกี่ยวข้องจำนวนน้อย เหมาะสำหรับที่อยู่ที่เชื่อมโยงกับบัญชีผู้ใช้ซึ่งโดยปกติแล้วจะต้องใช้ข้อมูลที่อยู่
• Subquery Loading: ใช้สำหรับความสัมพันธ์ที่ซับซ้อนหรือเมื่อจัดการกับข้อมูลที่เกี่ยวข้องจำนวนมากซึ่ง JOIN อาจไม่มีประสิทธิภาพ เหมาะสำหรับการโหลดความคิดเห็นในโพสต์บล็อก ซึ่งแต่ละโพสต์อาจมีความคิดเห็นจำนวนมาก
• Selectin Loading: ใช้สำหรับความสัมพันธ์แบบหนึ่งต่อกลุ่ม โดยเฉพาะอย่างยิ่งเมื่อจัดการกับอ็อบเจ็กต์หลักจำนวนมาก นี่มักจะเป็นตัวเลือกเริ่มต้นที่ดีที่สุดสำหรับการโหลดความสัมพันธ์แบบหนึ่งต่อกลุ่มอย่างกระตือรือร้น

ตัวอย่างเชิงปฏิบัติและแนวทางปฏิบัติที่ดีที่สุด

ลองพิจารณาสถานการณ์จริง: แพลตฟอร์มโซเชียลมีเดียที่ผู้ใช้สามารถติดตามซึ่งกันและกันได้ ผู้ใช้แต่ละคนมีรายชื่อผู้ติดตามและรายชื่อผู้ที่ถูกติดตาม (ผู้ใช้ที่พวกเขากำลังติดตาม) เราต้องการแสดงโปรไฟล์ของผู้ใช้พร้อมกับจำนวนผู้ติดตามและจำนวนผู้ที่ถูกติดตาม

แนวทางที่เรียบง่าย (Lazy Loading):

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    username = Column(String)
    followers = relationship("User", secondary='followers_association', primaryjoin='User.id==followers_association.c.followee_id', secondaryjoin='User.id==followers_association.c.follower_id', backref='following')

followers_association = Table('followers_association', Base.metadata, Column('follower_id', Integer, ForeignKey('users.id')), Column('followee_id', Integer, ForeignKey('users.id')))

user = session.query(User).filter_by(username='john_doe').first()

follower_count = len(user.followers) # กระตุ้นให้เกิดคำสั่งสืบค้นที่โหลดแบบ lazy
followee_count = len(user.following) # กระตุ้นให้เกิดคำสั่งสืบค้นที่โหลดแบบ lazy

print(f"User: {user.username}")
print(f"Follower Count: {follower_count}")
print(f"Following Count: {followee_count}")

โค้ดนี้ส่งผลให้เกิดคำสั่งสืบค้นสามรายการ: หนึ่งรายการเพื่อดึงผู้ใช้และสองคำสั่งสืบค้นเพิ่มเติมเพื่อดึงผู้ติดตามและผู้ที่ถูกติดตาม นี่คือตัวอย่างของปัญหา N+1

แนวทางที่ปรับให้เหมาะสม (Eager Loading):

user = session.query(User).options(selectinload(User.followers), selectinload(User.following)).filter_by(username='john_doe').first()

follower_count = len(user.followers)
followee_count = len(user.following)

print(f"User: {user.username}")
print(f"Follower Count: {follower_count}")
print(f"Following Count: {followee_count}")

ด้วยการใช้ `selectinload` สำหรับทั้ง `followers` และ `following` เราจะดึงข้อมูลที่จำเป็นทั้งหมดในคำสั่งสืบค้นเดียว (บวกกับคำสั่งสืบค้นผู้ใช้เริ่มต้น ดังนั้นทั้งหมดสองรายการ) สิ่งนี้ช่วยปรับปรุงประสิทธิภาพอย่างมีนัยสำคัญ โดยเฉพาะอย่างยิ่งสำหรับผู้ใช้ที่มีผู้ติดตามและผู้ที่ถูกติดตามจำนวนมาก

แนวทางปฏิบัติที่ดีที่สุดเพิ่มเติม:

• ใช้ `with_entities` สำหรับคอลัมน์เฉพาะ: เมื่อคุณต้องการเพียงไม่กี่คอลัมน์จากตาราง ให้ใช้ `with_entities` เพื่อหลีกเลี่ยงการโหลดข้อมูลที่ไม่จำเป็น ตัวอย่างเช่น `session.query(User.id, User.username).all()` จะดึงเฉพาะ ID และชื่อผู้ใช้เท่านั้น
• ใช้ `defer` และ `undefer` สำหรับการควบคุมแบบละเอียด: ตัวเลือก `defer` จะป้องกันไม่ให้คอลัมน์เฉพาะถูกโหลดในตอนแรก ในขณะที่ `undefer` ช่วยให้คุณโหลดได้ในภายหลังหากจำเป็น สิ่งนี้มีประโยชน์สำหรับคอลัมน์ที่มีข้อมูลจำนวนมาก (เช่น ช่องข้อความขนาดใหญ่หรือรูปภาพ) ที่ไม่จำเป็นต้องใช้เสมอไป
• สร้างโปรไฟล์คำสั่งสืบค้นของคุณ: ใช้ระบบเหตุการณ์ของ SQLAlchemy หรือเครื่องมือสร้างโปรไฟล์ฐานข้อมูลเพื่อระบุคำสั่งสืบค้นที่ช้าและพื้นที่สำหรับการเพิ่มประสิทธิภาพ เครื่องมือเช่น `sqlalchemy-profiler` อาจมีค่ามาก
• ใช้ดัชนีฐานข้อมูล: ตรวจสอบให้แน่ใจว่าตารางฐานข้อมูลของคุณมีดัชนีที่เหมาะสมเพื่อเพิ่มความเร็วในการดำเนินการคำสั่งสืบค้น ให้ความสนใจเป็นพิเศษกับดัชนีในคอลัมน์ที่ใช้ใน JOIN และ WHERE clause
• พิจารณาการแคช: ใช้งานกลไกการแคช (เช่น การใช้ Redis หรือ Memcached) เพื่อจัดเก็บข้อมูลที่เข้าถึงบ่อยและลดภาระในฐานข้อมูล SQLAlchemy มีตัวเลือกการรวมสำหรับการแคช

สรุป

การควบคุม lazy และ eager loading เป็นสิ่งจำเป็นสำหรับการเขียนแอปพลิเคชัน SQLAlchemy ที่มีประสิทธิภาพและปรับขนาดได้ ด้วยการทำความเข้าใจข้อดีข้อเสียระหว่างกลยุทธ์เหล่านี้และการนำแนวทางปฏิบัติที่ดีที่สุดไปใช้ คุณสามารถเพิ่มประสิทธิภาพคำสั่งสืบค้นฐานข้อมูล ลดปัญหา N+1 และปรับปรุงประสิทธิภาพของแอปพลิเคชันโดยรวม อย่าลืมสร้างโปรไฟล์คำสั่งสืบค้นของคุณ ใช้กลยุทธ์ eager loading ที่เหมาะสม และใช้ประโยชน์จากดัชนีฐานข้อมูลและการแคชเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด สิ่งสำคัญคือต้องเลือกกลยุทธ์ที่เหมาะสมตามความต้องการเฉพาะของคุณและรูปแบบการเข้าถึงข้อมูล พิจารณาผลกระทบระดับโลกของตัวเลือกของคุณ โดยเฉพาะอย่างยิ่งเมื่อจัดการกับผู้ใช้และฐานข้อมูลที่กระจายอยู่ทั่วภูมิภาคทางภูมิศาสตร์ต่างๆ เพิ่มประสิทธิภาพสำหรับกรณีทั่วไป แต่เตรียมพร้อมเสมอที่จะปรับกลยุทธ์การโหลดของคุณเมื่อแอปพลิเคชันของคุณพัฒนาขึ้นและรูปแบบการเข้าถึงข้อมูลของคุณเปลี่ยนแปลงไป ตรวจสอบประสิทธิภาพของคำสั่งสืบค้นของคุณเป็นประจำและปรับกลยุทธ์การโหลดของคุณตามนั้นเพื่อรักษาประสิทธิภาพที่เหมาะสมเมื่อเวลาผ่านไป