Como pensar em armazenamentos de dados em vez de bancos de dados?

Question

Como exemplo, o Google App Engine usa Google Datastore, não um banco de dados padrão, para armazenar dados. Alguém tem alguma dica para usar o Google Datastore em vez de bancos de dados? Parece que eu tenho treinado minha mente para pensar 100% nas relações de objeto que mapeiam diretamente para estruturas de tabela, e agora é difícil ver algo diferente. Posso entender alguns dos benefícios do Google Datastore (por exemplo, o desempenho ea capacidade de distribuir dados), mas algumas funcionalidades de banco de dados bom é sacrificado (por exemplo, junta).

Alguém que já trabalhou com o Google Datastore ou BigTable tem qualquer bons conselhos para trabalhar com eles?

Answer 1

Há duas coisas principais para se acostumar com o armazenamento de dados do App Engine quando comparado com bancos de dados relacionais 'tradicionais':

• O armazenamento de dados não faz distinção entre inserções e atualizações. Quando você liga para colocar () em uma entidade, essa entidade fica armazenado no armazenamento de dados com sua chave única, e qualquer coisa que tenha a chave fica substituído. Basicamente, cada tipo de entidade no armazenamento de dados funciona como um mapa enorme ou lista ordenada.
• Consultando, como você aludiu, é muito mais limitado. Sem junta-se, para começar.

A principal coisa a perceber - ea razão por trás dessas diferenças tanto - é que Bigtable, basicamente, funciona como um dicionário ordenado enorme. Assim, uma operação de colocar apenas define o valor para uma determinada chave - independentemente de qualquer valor anterior para essa chave, e buscar operações estão limitadas a buscar as chaves individuais ou intervalos contíguos de chaves. consultas mais sofisticadas são possíveis com os índices, que são basicamente apenas tabelas de conta própria, o que lhe permite implementar consultas mais complexas como varreduras em intervalos contíguos.

Uma vez que você absorveu isso, você tem o conhecimento básico necessário para compreender as capacidades e limitações de armazenamento de dados. Restrições que pode ter parecido arbitrária provavelmente fazer mais sentido.

O importante aqui é que, embora estes são restrições sobre o que você pode fazer em um banco de dados relacional, essas mesmas restrições são o que tornam prático para escalar até o tipo de magnitude que Bigtable é projetado para lidar. Você simplesmente não pode executar o tipo de consulta que parece bom no papel, mas é atrozmente lento em um banco de dados SQL.

Em termos de como alterar como você representar dados, a coisa mais importante é precalculation. Em vez de fazer junta-se a consulta tempo, dados precalculate e armazená-lo no armazenamento de dados, sempre que possível. Se você quer escolher um registro aleatório, gerar um número aleatório e armazená-lo com cada registro. Há um livro de receitas todo este tipo de dicas e truques aqui EDIT: O livro de receitas não está mais na existência.

Answer 2

A forma como eu ter sido indo sobre o interruptor mente é esquecer o banco de dados completamente.

No mundo db relacional você sempre tem que se preocupar com a normalização de dados e sua estrutura de tabela. Vala tudo. Apenas o layout de sua página web. Lay-los todos para fora. Agora olhe para eles. Você já 2/3 está lá.

Se você esquecer a noção de que o tamanho importa banco de dados e os dados não devem ser duplicados, então você está 3/4 lá e você nem sequer tem que escrever qualquer código! Deixe a sua opinião ditar seus modelos. Você não tem que levar seus objetos e torná-los 2 dimensional mais como no mundo relacional. Você pode armazenar objetos com forma agora.

Sim, esta é uma explicação simplificada da provação, mas me ajudou a esquecer-se sobre bancos de dados e fazer apenas uma aplicação. Fiz 4 App Engine os aplicativos até agora usando esta filosofia e há mais por vir.

Answer 3

Eu sempre rir quando as pessoas saem com - não é relacional. Eu escrevi cellectr no Django e aqui está um trecho do meu modelo a seguir. Como você vai ver, eu tenho ligas que são gerenciados ou treinados por usuários. Posso partir de uma liga obter todos os gestores, ou a partir de um determinado usuário posso devolver os treinadores liga ela ou gerentes.

Só porque não há suporte chave estrangeira específica não significa que você não pode ter um modelo de banco de dados com relacionamentos.

Meus dois pence.

---

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

Answer 4

Eu vim do mundo banco de dados relacional, em seguida, eu encontrei essa coisa Datastore. foram necessários vários dias para obter jeito dele. bem, há algumas de minhas descobertas.

Você deve ter já sabe que Datastore é construir a escala e que é a coisa que o separa de RDMBS. a escala melhor com grandes conjuntos de dados, o App Engine tem feito algumas mudanças (alguns meios série de mudanças).

RDBMS VS DataStore
Estrutura
No banco de dados, que geralmente estruturar nossos dados em tabelas, linhas que está no armazenamento de dados torna-se tipos e Entidades .

Relações
Em RDBMS, A maioria das pessoas folllows o One-to-One, muitos-para-um, muitos-para-muitos, no armazenamento de dados, já que tem "No associações" coisa, mas ainda podemos alcançar o nosso normalização usando " ReferenceProperty " eg One-to-One Relacionamento exemplo .

Índices
Normalmente em RDMBS fazemos índices como chave primária, chave estrangeira, chave exclusiva e uma chave índice para acelerar a busca e aumentar o nosso desempenho de banco de dados. No armazenamento de dados, você tem que fazer pelo menos um índice por tipo (ele será automaticamente gerar quer você goste ou não) porque armazenamento de dados procurar sua entidade com base destes índices e acreditem que é a melhor parte, em RDBMS você pode pesquisar usando campo não-índice que vai demorar algum tempo, mas ele vai. Em Datastore você não pode pesquisar usando propriedade não-índice.

Conde
Em RDMBS, é muito mais fácil de COUNT (*), mas em armazenamento de dados, por favor, não pense mesmo que de forma normal (Sim, há uma função count), pois tem 1000 limite e vai custar tanto small opertion como a entidade que não é bom, mas temos sempre boas escolhas, podemos usar Shard Contadores .

únicas restrições
Em RDMBS, nós amamos este direito de recurso? mas Datastore tem sua própria maneira. você não pode definir uma propriedade como única :(.

Consulta
GAE Datatore fornece um recurso melhor muito COMO (Oh não! armazenamento de dados não tem COMO palavra-chave) SQL que é GQL .

Data Insert / update / delete / Select
Este onde todos nós estão em interessado, como em RDMBS exigimos uma consulta para Insert, Update, excluir e selecione apenas como RDBMS, Datastore colocou, excluir, obter (não fique muito animado) porque Datastore colocar ou obter em termos de escrever, ler, pequenas operações (Leia Os custos de armazenamento de dados chamadas ) e é onde Modelagem de dados entra em ação. você tem que minimizar essas operações e manter seu aplicativo em execução. Para a Redução Leia você pode usar Memcache .

Answer 5

Dê uma olhada na documentação do Objectify. O primeiro comentário na parte inferior da página diz:

"Nice, embora você escreveu isso para descrever Objectify, é também um dos mais explicação concisa de appengine armazenamento de dados em si que eu já li. Obrigado."

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

Answer 6

Se você está acostumado a pensar sobre entidades mapeadas-ORM, então, que é basicamente como um armazenamento de dados à base de entidade como o Google App Engine funciona. Para algo como junta-se, você pode olhar para propriedades de referência . Você realmente não precisa se preocupar sobre se ele usa BigTable para o backend ou qualquer outra coisa desde o backend é captada pelas interfaces API GQL e armazenamento de dados.

Answer 7

A maneira que eu olhar para armazenamento de dados é, identifica tipo mesa, per se, e entidade é linha individual dentro da tabela. Se o Google fosse para tirar tipo do que o seu apenas um grande mesa com nenhuma estrutura e você pode despejar tudo o que você quer em uma entidade. Em outras palavras, se as entidades não estão vinculados a um tipo você praticamente pode ter qualquer estrutura a uma entidade e armazenar em um local (uma espécie de grande arquivo com nenhuma estrutura para ele, cada linha tem estrutura própria).

Agora, de volta ao comentário original, google armazenamento de dados e bigtable são duas coisas diferentes por isso não confundir google armazenamento de dados para armazenamento de dados sentido de armazenamento de dados. Bigtable é mais caro do que bigquery (Principal razão nós não ir com ele). Bigquery tem adequada junta e RDBMS como a linguagem SQL e seu mais barato, por que não usar o BigQuery. Dito isto, o BigQuery tem algumas limitações, dependendo do tamanho dos dados que você pode ou não pode encontrá-los.

Além disso, em termos de pensamento em termos de armazenamento de dados, eu acho declaração adequada seria "pensar em termos de bancos de dados NoSQL". Não há muitos deles fora disponíveis estes dias, mas quando se trata de produtos do Google, exceto o Google Cloud SQL (que é mySQL) tudo o resto é NoSQL.

Answer 8

Radicada no mundo do banco de dados, um armazenamento de dados para mim seria uma mesa gigante (daí o nome "Bigtable"). BigTable é um mau exemplo, porque embora ele faz um monte de outras coisas que um banco de dados típico pode não fazer e, no entanto, ainda é um banco de dados. As possibilidades são, a menos que você sabe que você precisa para construir algo como "bigtable", você provavelmente vai ficar bem do Google com um banco de dados padrão. Eles precisam que porque eles estão lidando com quantidades insanas de dados e sistemas em conjunto, e nenhum sistema disponível no mercado pode realmente fazer o trabalho da maneira exata que pode demonstrar que eles precisam do trabalho a ser feito.

(referência bigtable: http://en.wikipedia.org/wiki/BigTable )