데이터베이스 대신 데이터 저장소에서 생각하는 방법?

데이터베이스 대신 데이터 저장소에서 생각하는 방법?

---

예를 들어 Google App Engine은 표준 데이터베이스가 아닌 Google 데이터 스토어를 사용하여 데이터를 저장합니다. 데이터베이스 대신 Google Datastore를 사용하기위한 팁이 있습니까? 테이블 구조에 직접 매핑되는 객체 관계를 100 % 생각하도록 마음을 훈련 한 것 같습니다. 이제는 다르게 볼 수 없습니다. Google 데이터 스토어의 이점 (예 : 성능 및 데이터 배포 기능)을 이해할 수 있지만 데이터베이스 기능이 뛰어납니다 (예 : 조인).

Google Datastore 또는 BigTable과 함께 일한 사람이 그들과 협력 할 때 좋은 조언이 있습니까?

---

'전통적인'관계형 데이터베이스와 비교할 때 App Engine 데이터 저장소에 익숙해 져야 할 두 가지 주요 사항이 있습니다.

• 데이터 스토어는 삽입과 업데이트를 구분하지 않습니다. 엔터티에서 put ()을 호출하면 해당 엔터티가 고유 키로 데이터 스토어에 저장되고 해당 키가있는 모든 항목을 덮어 씁니다. 기본적으로 데이터 스토어의 각 엔티티 종류는 막대한 맵 또는 정렬 된 목록처럼 작동합니다.
• 언급했듯이 쿼리는 훨씬 제한적입니다. 시작을위한 조인이 없습니다.

Bigtable이 기본적으로 막대한 순서 사전과 같은 역할을한다는 점을 인식해야합니다. 따라서 넣기 조작은 해당 키의 이전 값에 관계없이 주어진 키의 값을 설정하기 만하며 페치 조작은 단일 키 또는 연속 된 키 범위 페치로 제한됩니다. 기본적으로 자체 테이블 인 인덱스를 사용하여보다 정교한 쿼리를 수행 할 수 있으므로 더 복잡한 쿼리를 연속 범위의 스캔으로 구현할 수 있습니다.

이를 이해하면 데이터 스토어의 기능과 한계를 이해하는 데 필요한 기본 지식을 얻게됩니다. 임의적으로 보일 수있는 제한 사항이 더 의미가있을 수 있습니다.

여기서 중요한 것은 관계형 데이터베이스에서 수행 할 수있는 작업에 대한 제한 사항이지만 이러한 동일한 제한 사항으로 인해 Bigtable이 처리하도록 설계된 정도까지 확장 할 수 있습니다. 종이에는 좋지만 SQL 데이터베이스에서는 엄청나게 느린 일종의 쿼리를 실행할 수 없습니다.

데이터 표현 방식을 변경하는 방법에서 가장 중요한 것은 사전 계산입니다. 쿼리시 조인을 수행하는 대신 데이터를 미리 계산하여 가능한 경우 데이터 저장소에 저장하십시오. 임의의 레코드를 선택하려면 임의의 숫자를 생성하고 각 레코드와 함께 저장하십시오. 여기에 이러한 종류의 팁과 요령에 대한 전체 요리 책이 있습니다. 편집 : 요리 책이 더 이상 존재하지 않습니다.

---

내가 마음의 전환에 대해 가고있는 방법은 데이터베이스를 모두 잊어 버리는 것입니다.

관계형 db 세계에서는 항상 데이터 정규화 및 테이블 구조에 대해 걱정해야합니다. 다 버려 웹 페이지를 레이아웃하면됩니다. 그들을 모두 배치하십시오. 이제 그들을보십시오. 이미 2/3입니다.

데이터베이스 크기가 중요하고 데이터를 복제해서는 안된다는 개념을 잊어 버린 경우 3/4에 도달했으며 코드를 작성할 필요조차 없습니다! 뷰가 모델을 지시하게하십시오. 관계 세계 에서처럼 더 이상 객체를 가져 와서 2 차원으로 만들 필요가 없습니다. 이제 모양이있는 객체를 저장할 수 있습니다.

예, 이것은 시련에 대한 간단한 설명이지만 데이터베이스를 잊어 버리고 응용 프로그램을 만드는 데 도움이되었습니다. 이 철학을 사용하여 지금까지 4 개의 App Engine 앱을 만들었으며 앞으로 더 많은 것들이 있습니다.

---

사람들이 나올 때 나는 항상 멍청하다-그것은 관계가 없다. 나는 django로 cellectr를 작성했으며 다음은 내 모델의 스 니펫입니다. 보시다시피, 사용자가 관리하거나 코치하는 리그가 있습니다. 리그에서 모든 관리자를 얻거나 지정된 사용자로부터 코치 또는 관리자로 리그를 반환 할 수 있습니다.

특정 외래 키 지원이 없다고해서 관계가있는 데이터베이스 모델을 가질 수 없다는 의미는 아닙니다.

내 두 펜스.

---

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
Structure
In database, we usually structure our data in Tables, Rows which is in Datastore it becomes Kinds and Entities.

Relations
In RDBMS, Most of the people folllows the One-to-One, Many-to-One, Many-to-Many relationship, In Datastore, As it has "No Joins" thing but still we can achieve our normalization using "ReferenceProperty" e.g. One-to-One Relationship Example .

Indexes
Usually in RDMBS we make indexes like Primary Key, Foreign Key, Unique Key and Index key to speed up the search and boost our database performance. In datastore, you have to make atleast one index per kind(it will automatically generate whether you like it or not) because datastore search your entity on the basis of these indexes and believe me that is the best part, In RDBMS you can search using non-index field though it will take some time but it will. In Datastore you can not search using non-index property.

Count
In RDMBS, it is much easier to count(*) but in datastore, Please dont even think it in normal way(Yeah there is a count function) as it has 1000 Limit and it will cost as much small opertion as the entity which is not good but we always have good choices, we can use Shard Counters.

Unique Constraints
In RDMBS, We love this feature right? but Datastore has its own way. you cannot define a property as unique :(.

Query
GAE Datatore provides a better feature much LIKE(Oh no! datastore does not have LIKE Keyword) SQL which is GQL.

Data Insert/Update/Delete/Select
This where we all are interested in, as in RDMBS we require one query for Insert, Update, Delete and Select just like RDBMS, Datastore has put, delete, get(dont get too excited) because Datastore put or get in terms of Write, Read, Small Operations(Read Costs for Datastore Calls) and thats where Data Modeling comes into action. you have to minimize these operations and keep your app running. For Reducing Read operation you can use Memcache.

---

Take a look at the Objectify documentation. The first comment at the bottom of the page says:

"Nice, although you wrote this to describe Objectify, it is also one of the most concise explanation of appengine datastore itself I've ever read. Thank you."

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

---

If you're used to thinking about ORM-mapped entities then that's basically how an entity-based datastore like Google's App Engine works. For something like joins, you can look at reference properties. You don't really need to be concerned about whether it uses BigTable for the backend or something else since the backend is abstracted by the GQL and Datastore API interfaces.

---

The way I look at datastore is, kind identifies table, per se, and entity is individual row within table. If google were to take out kind than its just one big table with no structure and you can dump whatever you want in an entity. In other words if entities are not tied to a kind you pretty much can have any structure to an entity and store in one location (kind of a big file with no structure to it, each line has structure of its own).

Now back to original comment, google datastore and bigtable are two different things so do not confuse google datastore to datastore data storage sense. Bigtable is more expensive than bigquery (Primary reason we didn't go with it). Bigquery does have proper joins and RDBMS like sql language and its cheaper, why not use bigquery. That being said, bigquery does have some limitations, depending on size of your data you might or might not encounter them.

Also, in terms of thinking in terms of datastore, i think proper statement would have been "thinking in terms of NoSQL databases". There are too many of them available out there these days but when it comes to google products except google cloud SQL (which is mySQL) everything else is NoSQL.

---

Being rooted in the database world, a data store to me would be a giant table (hence the name "bigtable"). BigTable is a bad example though because it does a lot of other things that a typical database might not do, and yet it is still a database. Chances are unless you know you need to build something like Google's "bigtable", you will probably be fine with a standard database. They need that because they are handling insane amounts of data and systems together, and no commercially available system can really do the job the exact way they can demonstrate that they need the job to be done.

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

참고URL : https://stackoverflow.com/questions/103727/how-to-think-in-data-stores-instead-of-databases