วิธีคิดในที่เก็บข้อมูลแทนที่จะเป็นฐานข้อมูล

ตัวอย่างเช่น Google App Engine ใช้ Google Datastore ไม่ใช่ฐานข้อมูลมาตรฐานในการจัดเก็บข้อมูล ใครบ้างมีเคล็ดลับในการใช้ Google Datastore แทนที่จะเป็นฐานข้อมูล ดูเหมือนว่าฉันได้ฝึกจิตใจให้คิด 100% ในความสัมพันธ์ของวัตถุที่แมปกับโครงสร้างของตารางโดยตรงและตอนนี้มันยากที่จะเห็นสิ่งที่แตกต่าง ฉันสามารถเข้าใจถึงประโยชน์บางประการของ Google Datastore (เช่นประสิทธิภาพและความสามารถในการเผยแพร่ข้อมูล) แต่ฟังก์ชั่นฐานข้อมูลที่ดีบางอย่างเสียสละ (เช่นเชื่อมต่อ)

ใครบ้างที่ทำงานกับ Google Datastore หรือ BigTable มีคำแนะนำที่ดีในการทำงานกับพวกเขาบ้างไหม?

มีสองสิ่งสำคัญที่ควรทำความคุ้นเคยกับเกี่ยวกับที่เก็บข้อมูลของ App Engine เมื่อเปรียบเทียบกับฐานข้อมูลเชิงสัมพันธ์ 'ดั้งเดิม':

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

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

เมื่อคุณเข้าใจแล้วคุณมีความรู้พื้นฐานที่จำเป็นในการทำความเข้าใจความสามารถและข้อ จำกัด ของที่เก็บข้อมูล ข้อ จำกัด ที่อาจดูเหมือนไม่มีเหตุผลอาจมีเหตุผลมากกว่า

สิ่งสำคัญที่นี่คือแม้ว่าสิ่งเหล่านี้จะมีข้อ จำกัด มากกว่าสิ่งที่คุณสามารถทำได้ในฐานข้อมูลเชิงสัมพันธ์ แต่ข้อ จำกัด เดียวกันเหล่านี้คือสิ่งที่ทำให้การขยายขอบเขตของขนาดที่ Bigtable ออกแบบมาเพื่อใช้งานได้จริง คุณไม่สามารถดำเนินการเรียงลำดับของแบบสอบถามที่ดูดีบนกระดาษ แต่ช้าในฐานข้อมูล SQL อย่างเลวร้าย

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

วิธีที่ฉันจะเปลี่ยนใจในใจก็คือการลืมฐานข้อมูลทั้งหมด

ในโลกสัมพันธ์เชิงสัมพันธ์คุณต้องกังวลเกี่ยวกับการทำให้ข้อมูลเป็นปกติและโครงสร้างตารางของคุณ ทิ้งไว้ทั้งหมด เพียงแค่จัดวางหน้าเว็บของคุณ วางทั้งหมด ตอนนี้ดูที่พวกเขา คุณมี 2/3 แล้ว

หากคุณลืมความคิดที่ว่าขนาดฐานข้อมูลมีความสำคัญและข้อมูลไม่ควรซ้ำซ้อนคุณก็อยู่ที่นั่น 3/4 และคุณไม่จำเป็นต้องเขียนโค้ดใด ๆ ! ให้มุมมองของคุณกำหนดรุ่นของคุณ คุณไม่จำเป็นต้องนำวัตถุของคุณและทำให้มันเป็นสองมิติอีกต่อไปเหมือนในโลกแห่งความสัมพันธ์ คุณสามารถจัดเก็บวัตถุที่มีรูปร่างได้ในขณะนี้

ใช่นี่เป็นคำอธิบายที่ง่ายของการทดสอบ แต่มันช่วยให้ฉันลืมเกี่ยวกับฐานข้อมูลและเพิ่งสร้างแอปพลิเคชัน ฉันได้สร้างแอพ App Engine ถึง 4 แอปโดยใช้ปรัชญานี้และมีอีกมากที่จะมา

ฉันหัวเราะเบา ๆ เสมอเมื่อผู้คนออกมาด้วย - มันไม่สัมพันธ์กัน ฉันได้เขียน cellectr ใน django และนี่เป็นตัวอย่างของแบบจำลองของฉันด้านล่าง อย่างที่คุณเห็นฉันมีลีกที่ผู้ใช้จัดการหรือเป็นโค้ช ฉันทำได้จากลีกเพื่อรับผู้จัดการทั้งหมดหรือจากผู้ใช้ที่กำหนดฉันสามารถส่งคืนลีกที่เธอเป็นโค้ชหรือผู้จัดการได้

เพียงเพราะไม่มีการสนับสนุนคีย์ต่างประเทศเฉพาะไม่ได้หมายความว่าคุณไม่สามารถมีรูปแบบฐานข้อมูลที่มีความสัมพันธ์

เพนนีของฉันสองคน

class League(BaseModel):
    name = db.StringProperty()    
    managers = db.ListProperty(db.Key) #all the users who can view/edit this league
    coaches = db.ListProperty(db.Key) #all the users who are able to view this league

    def get_managers(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.managers)

    def get_coaches(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.coaches)      

    def __str__(self):
        return self.name

    # Need to delete all the associated games, teams and players
    def delete(self):
        for player in self.leagues_players:
            player.delete()
        for game in self.leagues_games:
            game.delete()
        for team in self.leagues_teams:
            team.delete()            
        super(League, self).delete()

class UserPrefs(db.Model):
    user = db.UserProperty()
    league_ref = db.ReferenceProperty(reference_class=League,
                            collection_name='users') #league the users are managing

    def __str__(self):
        return self.user.nickname

    # many-to-many relationship, a user can coach many leagues, a league can be
    # coached by many users
    @property
    def managing(self):
        return League.gql('WHERE managers = :1', self.key())

    @property
    def coaching(self):
        return League.gql('WHERE coaches = :1', self.key())

    # remove all references to me when I'm deleted
    def delete(self):
        for manager in self.managing:
            manager.managers.remove(self.key())
            manager.put()
        for coach in self.managing:
            coach.coaches.remove(self.key())
            coaches.put()            
        super(UserPrefs, self).delete()    

ฉันมาจากฐานข้อมูลเชิงสัมพันธ์โลกจากนั้นฉันก็พบสิ่งนี้ดาต้าสโตร์ มันใช้เวลาหลายวันกว่าจะหยุดมัน มีการค้นพบของฉันอยู่บ้าง

คุณต้องรู้อยู่แล้วว่า Datastore สร้างขึ้นเพื่อปรับขนาดและนั่นคือสิ่งที่แยกออกจาก RDMBS เพื่อขยายขนาดให้ดีขึ้นด้วยชุดข้อมูลขนาดใหญ่ App Engine ได้ทำการเปลี่ยนแปลงบางอย่าง (บางครั้งก็หมายถึงการเปลี่ยนแปลงจำนวนมาก)

RDBMS VS DataStore
โครงสร้าง
ในฐานข้อมูลของเรามักจะจัดโครงสร้างข้อมูลของเราในตารางแถวซึ่งอยู่ใน Datastore มันจะกลายเป็นชนิดและหน่วยงาน

ความสัมพันธ์
ใน RDBMS ผู้คนส่วนใหญ่มีความสัมพันธ์แบบ One-to-One, One-One, One-to-One, ใน Datastore เนื่องจากมี "No Joins" แต่เรายังสามารถบรรลุมาตรฐานของเราได้โดยใช้ " ReferenceProperty " "เช่นOne-to-One ตัวอย่างความสัมพันธ์

ดัชนี
มักจะอยู่ใน RDMBS เราสร้างดัชนีเช่นคีย์หลัก, คีย์ต่างประเทศ, คีย์เฉพาะและคีย์ดัชนีเพื่อเพิ่มความเร็วในการค้นหาและเพิ่มประสิทธิภาพฐานข้อมูลของเรา ในดาต้าสโตร์คุณต้องสร้างอย่างน้อยหนึ่งดัชนีต่อชนิด (มันจะสร้างโดยอัตโนมัติไม่ว่าคุณจะชอบหรือไม่) เพราะดาต้าสโตร์ค้นหาเอนทิตีของคุณบนพื้นฐานของดัชนีเหล่านี้และเชื่อฉันว่าเป็นส่วนที่ดีที่สุดใน RDBMS เขตข้อมูลที่ไม่ใช่ดัชนีแม้ว่ามันจะใช้เวลาพอสมควร แต่มันจะ ใน Datastore คุณไม่สามารถค้นหาโดยใช้คุณสมบัติที่ไม่ใช่ดัชนี

นับ
ใน RDMBS มันเป็นเรื่องง่ายมากที่จะนับ (*) แต่ในการเก็บข้อมูล, โปรดอย่าได้คิดว่ามันในทางปกติ (ใช่มีฟังก์ชั่นการนับ) มันมีจำกัด 1000และมันจะมีค่าใช้จ่ายเท่าopertion ขนาดเล็กเป็นนิติบุคคลที่ ไม่ดี แต่เรามีตัวเลือกที่ดีอยู่เสมอเราสามารถใช้Shard Countersได้

ข้อ จำกัด เฉพาะ
ใน RDMBS เราชอบคุณสมบัตินี้ใช่ไหม แต่ Datastore มีวิธีการของตัวเอง คุณไม่สามารถกำหนดคุณสมบัติให้เป็นเอกลักษณ์ :(

แบบสอบถาม
GAE Datatore มีคุณสมบัติที่ดีมากเช่น (โอ้ไม่! เก็บข้อมูลไม่ได้เช่นคำหลัก) SQL ซึ่งเป็นgql

การแทรกข้อมูล / อัปเดต / ลบ / เลือก
นี่คือสิ่งที่เราทุกคนสนใจเช่นเดียวกับใน RDMBS เราต้องการหนึ่งแบบสอบถามสำหรับแทรกอัปเดตลบและเลือกเช่นเดียวกับ RDBMS Datastore ได้ใส่ลบรับ (ไม่ตื่นเต้นเกินไป) เพราะ Datastore ใส่หรือรับในแง่ของการเขียน, อ่าน, การดำเนินการขนาดเล็ก (อ่านค่าใช้จ่ายสำหรับการโทรดาต้าสโตร์ ) และนั่นคือสิ่งที่การสร้างแบบจำลองข้อมูลเข้ามาดำเนินการ คุณต้องลดการทำงานเหล่านี้และทำให้แอปของคุณทำงานต่อไป เพื่อลดการดำเนินการอ่านคุณสามารถใช้Memcache

ลองดูที่เอกสารอธิบายวัตถุประสงค์ ความคิดเห็นแรกที่ด้านล่างของหน้าพูดว่า:

"ดีมากแม้ว่าคุณจะเขียนสิ่งนี้เพื่ออธิบาย Objectify แต่ก็เป็นหนึ่งในคำอธิบายที่กระชับที่สุดของ appengine datastore ที่ฉันเคยอ่านมาแล้วขอบคุณ"

https://github.com/objectify/objectify/wiki/Concepts

หากคุณเคยนึกถึงเอนทิตีที่แมปแบบ ORM นั่นก็เป็นวิธีที่ดาต้าสโตร์ที่ใช้เอนทิตี้ของอย่าง App Engine ของ Google ทำงาน สำหรับสิ่งที่ต้องการรวมคุณสามารถดูคุณสมบัติการอ้างอิงได้ คุณไม่จำเป็นต้องกังวลเกี่ยวกับว่าจะใช้ BigTable สำหรับแบ็กเอนด์หรืออย่างอื่นเพราะแบ็กเอนด์นั้นถูกแยกออกโดยอินเตอร์เฟส GQL และ Datastore API

วิธีที่ฉันดูดาต้าสโตร์คือ, ชนิดระบุตาราง, ต่อ se, และเอนทิตีคือแต่ละแถวภายในตาราง หาก google ถูกนำออกมาให้ดีกว่าโต๊ะใหญ่ที่ไม่มีโครงสร้างและคุณสามารถทิ้งสิ่งที่คุณต้องการในเอนทิตี กล่าวอีกนัยหนึ่งถ้าเอนทิตีไม่ผูกติดอยู่กับชนิดของคุณคุณสามารถมีโครงสร้างใด ๆ กับเอนทิตีและเก็บไว้ในที่เดียวได้ (ชนิดของไฟล์ขนาดใหญ่ที่ไม่มีโครงสร้างให้แต่ละบรรทัดมีโครงสร้างเป็นของตัวเอง)

ตอนนี้กลับไปที่ความคิดเห็นดั้งเดิม Google datastore และ bigtable เป็นสองสิ่งที่แตกต่างกันดังนั้นอย่าสับสนระหว่าง google datastore กับ datastore data sense Bigtable มีราคาแพงกว่าการสืบค้นขนาดใหญ่ (เหตุผลหลักที่เราไม่ได้ไปด้วย) Bigquery มีการเชื่อมต่อที่เหมาะสมและ RDBMS เช่นภาษา SQL และราคาถูกกว่าทำไมไม่ใช้ Bigquery ตามที่กล่าวมาการค้นหาครั้งใหญ่มีข้อ จำกัด บางประการขึ้นอยู่กับขนาดของข้อมูลที่คุณอาจพบหรือไม่พบ

นอกจากนี้ในแง่ของการคิดในแง่ของดาต้าสโตร์ฉันคิดว่าข้อความที่เหมาะสมน่าจะเป็น "การคิดในแง่ของฐานข้อมูล NoSQL" มีมากเกินไปของพวกเขาออกมีวันนี้ แต่เมื่อมันมาถึงผลิตภัณฑ์ของ Google ยกเว้น Google Cloud SQL (ซึ่งเป็น mySQL) ทุกอย่างอื่นคือ NoSQL

การถูกหยั่งรากในโลกของฐานข้อมูลนั้นแหล่งข้อมูลสำหรับฉันจะเป็นตารางยักษ์ (ดังนั้นชื่อ "bigtable") BigTable เป็นตัวอย่างที่ไม่ดีแม้ว่าจะทำสิ่งอื่น ๆ อีกมากมายที่ฐานข้อมูลทั่วไปอาจไม่ทำและยังเป็นฐานข้อมูล โอกาสที่จะเกิดขึ้นถ้าคุณไม่ทราบว่าคุณต้องสร้างบางสิ่งเช่น "bigtable" ของ Google คุณอาจจะใช้ฐานข้อมูลมาตรฐานได้ พวกเขาต้องการเพราะพวกเขากำลังจัดการข้อมูลและระบบจำนวนบ้าเข้าด้วยกันและไม่มีระบบที่พร้อมใช้งานในเชิงพาณิชย์สามารถทำงานได้อย่างแท้จริงในแบบที่พวกเขาสามารถแสดงให้เห็นว่าพวกเขาต้องการงานที่จะทำ

(การอ้างอิง bigtable: http://en.wikipedia.org/wiki/BigTable )