Veritabanları yerine veri depolarında nasıl düşünülür?

Örneğin, Google App Engine, verileri depolamak için standart bir veritabanı değil Google Veri Deposu'nu kullanır. Veritabanları yerine Google Veri Deposu'nu kullanmak için herhangi bir ipucu var mı? Görünüşe göre, doğrudan tablo yapılarıyla eşleşen nesne ilişkilerinde% 100 düşünmek için eğittim ve şimdi farklı bir şey görmek zor. Google Datastore'un bazı avantajlarını anlayabilirim (örneğin, performans ve veri dağıtma yeteneği), ancak bazı iyi veritabanı işlevleri feda edilir (örn. Birleştirmeler).

Google Datastore veya BigTable ile çalışan herkesin onlarla çalışmak için iyi bir tavsiyesi var mı?

'Geleneksel' ilişkisel veritabanlarıyla karşılaştırıldığında App Engine veri deposuna alışmak için iki temel şey vardır:

• Veri deposu, ekler ve güncellemeler arasında bir ayrım yapmaz. Bir varlık üzerinde put () öğesini çağırdığınızda, o varlık benzersiz anahtarıyla veri deposuna depolanır ve bu anahtarı içeren her şeyin üzerine yazılır. Temel olarak, veri deposundaki her varlık türü muazzam bir harita veya sıralı liste gibi davranır.
• Sorgulamak, bahsettiğiniz gibi, çok daha sınırlıdır. Başlangıç ​​için birleştirme yok.

Gerçekleşmesi gereken anahtar şey - ve bu iki farklılığın ardındaki neden - Bigtable'ın temelde muazzam sıralı bir sözlük gibi davranmasıdır. Bu nedenle, bir yerleştirme işlemi, belirli bir anahtarın değerini ayarlar - bu anahtar için önceki herhangi bir değerden bağımsız olarak ve getirme işlemleri, tek anahtarlar veya bitişik anahtar aralıkları getirme ile sınırlıdır. Temelde sadece kendi tabloları olan dizinlerle daha karmaşık sorgular mümkün olur ve bitişik aralıklarda tarama olarak daha karmaşık sorgular uygulamanızı sağlar.

Bunu aldıktan sonra, veri deposunun yeteneklerini ve sınırlamalarını anlamak için gereken temel bilgiye sahipsiniz. Keyfi görünmüş olabilecek kısıtlamalar muhtemelen daha mantıklıdır.

Buradaki anahtar şey, bunların ilişkisel bir veritabanında yapabilecekleriniz üzerindeki kısıtlamalar olmasına rağmen, aynı kısıtlamalar, Bigtable'ın işlemek için tasarladığı büyüklük derecesine kadar ölçeklendirmeyi pratik kılan şeydir. Kağıt üzerinde iyi görünen, ancak bir SQL veritabanında acımasızca yavaş olan bir sorgu türünü çalıştıramazsınız.

Verileri temsil etme şeklinizi nasıl değiştireceğiniz açısından en önemli şey önceden hesaplamadır. Sorgu zamanında birleştirmeler yapmak yerine, verileri önceden hesaplayın ve mümkün olan yerlerde veri deposunda saklayın. Rasgele bir kayıt seçmek istiyorsanız, rasgele bir sayı oluşturun ve her kayıtla birlikte saklayın. Burada bu tür ipuçları ve püf noktaları bir bütün yemek kitabı var Düzenleme: Yemek kitabı artık mevcut değil.

Zihin anahtarı hakkında gidiş yolu, veritabanı tamamen unutmak için.

İlişkisel db dünyasında her zaman veri normalizasyonu ve tablo yapınız hakkında endişelenmeniz gerekir. Her şeyi bırakın. Sadece web sayfanızı düzenleyin. Hepsini yerleştirin. Şimdi onlara bak. Zaten orada 2/3 konum.

Veritabanı boyutunun önemli olduğu ve verilerin çoğaltılmaması gerektiği fikrini unutursanız, orada 3/4'sünüz ve herhangi bir kod yazmak zorunda bile kalmazsınız! Görüşleriniz Modellerinizi dikte etsin. İlişkisel dünyada olduğu gibi artık nesnelerinizi alıp 2 boyutlu hale getirmenize gerek yok. Şimdi şekilli nesneleri saklayabilirsiniz.

Evet, bu çileğin basitleştirilmiş bir açıklaması, ancak veritabanlarını unutmam ve sadece bir uygulama yapmama yardımcı oldu. Şimdiye kadar bu felsefeyi kullanarak 4 App Engine uygulaması yaptım ve daha fazlası var.

İnsanlar ortaya çıktığında her zaman kıkırdarım - ilişkisel değil. Django'da cellectr yazdım ve işte aşağıda modelimin bir parçası. Gördüğünüz gibi, kullanıcılar tarafından yönetilen veya çalıştırılan liglerim var. Bir ligden tüm menajerleri alabilirim veya belirli bir kullanıcıdan koçluk veya menajerler ligine geri dönebilirim.

Belirli bir yabancı anahtar desteği olmaması, ilişkileri olan bir veritabanı modeline sahip olamayacağınız anlamına gelmez.

Benim iki peni.

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()    

İlişkisel Veritabanı dünyasından geldim ve sonra bu Veri Mağazası'nı buldum. asmak birkaç gün sürdü. bazı bulgularım var.

Datastore'un ölçekli olarak oluşturulduğunu ve onu RDMBS'den ayıran şey olduğunu zaten biliyor olmalısınız. büyük veri kümesiyle daha iyi ölçeklemek için App Engine bazı değişiklikler yaptı (bazıları çok fazla değişiklik anlamına geliyor).

RDBMS VS DataStore
Yapısı
Veritabanında, verilerimizi genellikle Veri Deposu'ndaki Türler ve Varlıklar haline gelen Tablolar, Satırlar halinde yapılandırırız .

RDBMS'de İlişkiler İnsanların çoğu Bire Bir, Çoktan Bire, Çoktan Çoka İlişkisi, Datastore'da, "Katılmamış" bir şey olduğu için, ama yine de " ReferenceProperty "örn. Bire Bir İlişki Örneği .

Dizinler
Genellikle RDMBS'de, aramayı hızlandırmak ve veritabanı performansımızı artırmak için Birincil Anahtar, Yabancı Anahtar, Benzersiz Anahtar ve Dizin anahtarı gibi dizinler yaparız. Veri deposunda, tür başına en az bir dizin oluşturmanız gerekir (beğenip beğenmediğinizotomatik olarak oluşturulur ) çünkü veri deposu kuruluşunuzu bu dizinlere göre arar ve bana en iyi bölüm olduğuna inanır, RDBMS'de kullanarak arama yapabilirsiniz endeks dışı alanı biraz zaman alacak ama alacaktır. Datastore'da dizin olmayan özelliği kullanarak arama yapamazsınız.

Saymak
RDMBS, saymak çok daha kolaydır (*) ama veri deposunda, 1000 Sınırı olduğu için normal şekilde bile düşünmeyin (Evet bir sayım işlevi vardır) ve varlık kadar küçük bir işlem maliyeti olacak iyi değil ama her zaman iyi seçeneklerimiz var, Kırık Sayaçları kullanabiliriz .

Benzersiz Kısıtlamalar
RDMBS'de bu özelliği seviyoruz değil mi? ama Datastore'un kendi yolu var. bir özelliği benzersiz olarak tanımlayamazsınız :(.

Sorgu
GAE'nin Datatore daha iyi bir özellik daha sağlamaktadır GİBİ olduğunu (Oh hayır! Veri deposu yok GİBİ Kelimeler) SQL GQL .

Veri Ekleme / Güncelleme / Silme / Seçme
Hepimizin ilgilendiği yer, RDMBS'de olduğu gibi, RDBMS gibi Ekle, Güncelle, Sil ve Seç için bir sorguya ihtiyacımız var, Datastore, Datastore'un koyduğu, sildiğini, aldığını (çok fazla heyecanlanmadığını) Yazma, Okuma, Küçük İşlemler ( Veri Deposu Çağrıları için Okuma Maliyetleri ) ve Veri Modellemenin yürürlüğe girdiği yerlere koyma veya alma . bu işlemleri en aza indirmeli ve uygulamanızı çalışır durumda tutmalısınız. Okuma işlemini azaltmak için Memcache kullanabilirsiniz .

Objectify belgelerine bir göz atın. Sayfanın altındaki ilk yorum şöyle diyor:

"Güzel, bunu Objectify'ı tanımlamak için yazmış olsanız da, aynı zamanda şimdiye kadar okuduğum appengine datastore'un en kısa açıklamalarından biri. Teşekkürler."

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

ORM eşlemeli varlıkları düşünmeye alışkınsanız, temel olarak Google'ın App Engine gibi varlık tabanlı bir veri deposu böyle çalışır. Birleşimler gibi bir şey için başvuru özelliklerine bakabilirsiniz . Arka uç GQL ve Datastore API arabirimleri tarafından soyutlandığından, arka uç için BigTable veya başka bir şey kullanıp kullanmadığı konusunda endişelenmenize gerek yoktur.

Veri deposuna bakma şeklim, tür tabloyu, kendi başına tanımlar ve varlık, tablo içindeki tek satırdır. Google, yapısı olmayan tek bir büyük tablosundan daha nazik olsaydı ve bir varlıkta ne istersen onu bırakabilirsin. Diğer bir deyişle, eğer varlıklar bir varlığa herhangi bir yapıya sahip olabilir ve bir yerde depolayabilirsiniz (herhangi bir yapıya sahip olmayan büyük bir dosya, her satırın kendi yapısı vardır).

Şimdi orijinal yoruma geri dönersek, google datastore ve bigtable iki farklı şeydir, bu nedenle google datastore'u veri deposu veri depolama anlamıyla karıştırmayın. Bigtable bigquery daha pahalı (onunla birlikte gitmedim birincil nedeni). Bigquery, sql dili ve daha ucuz gibi uygun birleştirme ve RDBMS'ye sahiptir, neden bigquery kullanmıyorsunuz? Bununla birlikte, bigquery'nin verilerinizin boyutuna bağlı olarak, bunlarla karşılaşabileceğiniz veya karşılaşmayabileceğiniz bazı sınırlamaları vardır.

Ayrıca, veri deposu açısından düşünme açısından, uygun ifadenin "NoSQL veritabanları açısından düşünme" olacağını düşünüyorum. Bugünlerde orada çok fazla var ama google bulut SQL (mySQL) hariç google ürünleri söz konusu olduğunda diğer her şey NoSQL'dir.

Veritabanı dünyasında kök salmış olmak, bana bir veri deposu dev bir tablo (dolayısıyla "bigtable" adı) olurdu. BigTable kötü bir örnektir, çünkü tipik bir veritabanının yapamayacağı birçok şey yapar ve yine de bir veritabanıdır. Google'ın "bigtable" gibi bir şey oluşturmanız gerektiğini bilmiyorsanız, muhtemelen standart bir veritabanı ile iyi olacaksınız. Buna ihtiyaç duyuyorlar çünkü çılgınca veri ve sistemleri bir arada ele alıyorlar ve ticari olarak mevcut hiçbir sistem işi gerçekten yapmaları gereken işe ihtiyaç duyduklarını gösterebilecekleri şekilde yapamıyor.

(bigtable referansı: http://en.wikipedia.org/wiki/BigTable )