¿Cómo pensar en almacenes de datos en lugar de bases de datos?

Question

Como ejemplo, Google App Engine utiliza almacenes de datos, no una base de datos, para almacenar datos. ¿Alguien tiene consejos para usar los almacenes de datos en lugar de las bases de datos? Parece que he entrenado mi mente para pensar al 100% en las relaciones de objeto que se asignan directamente a las estructuras de la tabla, y ahora es difícil ver algo diferente. Puedo entender algunos de los beneficios de los almacenes de datos (por ejemplo, el rendimiento y la capacidad de distribuir datos), pero se sacrifica alguna buena funcionalidad de base de datos (por ejemplo, uniones).

¿Alguien que haya trabajado con almacenes de datos como BigTable tiene algún buen consejo para trabajar con ellos?

Answer 1

Hay dos cosas principales para acostumbrarse a sobre el almacén de datos de App Engine en comparación con bases de datos relacionales 'tradicionales':

• El almacén de datos no hace distinción entre las inserciones y actualizaciones. Cuando llama a put() en una entidad, esa entidad se almacena en el almacén de datos con su clave única, y todo lo que tiene esa clave se sobrescribe. Básicamente, cada tipo de entidad en el almacén de datos actúa como un enorme mapa o lista ordenada.
• Las consultas, como ha mencionado, son mucho más limitadas. No se une, para empezar.

La clave para darse cuenta, y la razón detrás de estas dos diferencias, es que Bigtable básicamente actúa como un enorme diccionario ordenado. Por lo tanto, una operación put simplemente establece el valor para una clave determinada, independientemente de cualquier valor anterior para esa clave, y las operaciones de recuperación están limitadas a la obtención de claves individuales o rangos contiguos de claves.Se hacen posibles consultas más sofisticadas con índices, que básicamente son solo tablas, lo que le permite implementar consultas más complejas como escaneos en rangos contiguos.

Una vez que haya asimilado eso, tiene los conocimientos básicos necesarios para comprender las capacidades y limitaciones del almacén de datos. Las restricciones que pueden parecer arbitrarias probablemente tengan más sentido.

La clave aquí es que, aunque estas son restricciones sobre lo que puede hacer en una base de datos relacional, estas mismas restricciones son las que hacen que sea práctico escalar hasta el tipo de magnitud que está diseñado para manejar Bigtable. Simplemente no puede ejecutar el tipo de consulta que se ve bien en el papel, pero es atrozmente lenta en una base de datos SQL.

En términos de cómo cambiar la forma de representar datos, lo más importante es el cálculo previo. En lugar de hacer uniones en el momento de la consulta, precalcule los datos y guárdelos en el almacén de datos siempre que sea posible. Si desea elegir un registro aleatorio, genere un número aleatorio y almacénelo con cada registro. Hay un recetario completo de este tipo de consejos y trucos here Editar: El libro de cocina ya no existe.

Answer 2

Siendo enraizado en el mundo de la base de datos, un almacén de datos para mí sería una tabla gigante (de ahí el nombre "bigtable"). Sin embargo, BigTable es un mal ejemplo porque hace muchas otras cosas que una base de datos típica podría no hacer y, sin embargo, sigue siendo una base de datos. Lo más probable es que a menos que sepa que necesita construir algo así como la "gran tabla" de Google, probablemente esté bien con una base de datos estándar. Lo necesitan porque están manejando enormes cantidades de datos y sistemas juntos, y ningún sistema comercialmente disponible puede realmente hacer el trabajo de la manera exacta en que pueden demostrar que necesitan que se realice el trabajo.

(referencia Bigtable: http://en.wikipedia.org/wiki/BigTable)

Answer 3

La forma en que he estado yendo sobre el interruptor de la mente es olvidarse de la base de datos por completo.

En el mundo db relacional, siempre debe preocuparse por la normalización de datos y la estructura de su tabla. Deshazte de todo. Solo diseña tu página web. Dispóngalos a todos. Ahora míralo. Ya estás 2/3 allí.

Si olvida la noción de que el tamaño de la base de datos es importante y los datos no se deben duplicar, entonces tiene 3/4 y ¡ni siquiera tuvo que escribir ningún código! Deja que tus puntos de vista dicten tus Modelos. No es necesario que tome sus objetos y los vuelva bidimensionales como en el mundo relacional. Puede almacenar objetos con forma ahora.

Sí, esta es una explicación simplificada de la dura prueba, pero me ayudó a olvidar las bases de datos y simplemente hacer una solicitud. Hasta el momento, he hecho 4 aplicaciones de App Engine usando esta filosofía y aún quedan más.

Answer 4

Si está acostumbrado a pensar en entidades mapeadas ORM, básicamente así es como funciona un almacén de datos basado en entidades, como App Engine de Google. Para ver algo parecido a uniones, puede mirar reference properties. No necesita preocuparse si usa BigTable para el servidor o algo más, ya que las interfaces GQL y Datastore API abstraen el backend.

Answer 5

Siempre me río cuando salen las personas, no es relacional. He escrito cellectr en django y aquí hay un fragmento de mi modelo a continuación. Como verá, tengo ligas administradas o dirigidas por los usuarios. Puedo obtener de una liga a todos los gerentes, o de un usuario dado, puedo devolverle la liga a los entrenadores o gerentes.

El hecho de que no haya soporte de clave foránea no significa que no pueda tener un modelo de base de datos con relaciones.

Mis dos peniques.

---

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 6

Tome un vistazo a la documentación Objectify. El primer comentario en la parte inferior de la página dice:

"Bueno, aunque usted escribió esto para describir Objectify, también es una de las explicaciones más concisas de appengine datastore en sí misma que he leído. Gracias."

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

Answer 7

Salí del mundo Base de Datos Relacional Entonces me encontré con esta cosa almacén de datos. tomó varios días para entenderlo. Bueno, hay algunos de mis hallazgos.

Ya debe saber que Datastore está construido a escala y eso es lo que lo separa de RDMBS. para escalar mejor con un gran conjunto de datos, App Engine ha realizado algunos cambios (algunos significan muchos cambios).

RDBMS VS almacén de datos
Estructura
En la base de datos, por lo general estructurar nuestros datos en las tablas, filas, que está en el almacén de datos se convierte en Kinds and Entities.

Relaciones
En RDBMS, la mayoría de la gente folllows el uno-a-uno, muchos-a-uno, muchos-a-muchos relación, En Almacenamiento de datos, ya que no tiene "une" cosa pero aún podemos lograr nuestra normalización usando "ReferenceProperty" por ejemplo One-to-One Relationship Example.

Indexes
lo general, en RDMBS hacemos índices como clave primaria, clave externa, clave única y la clave de índice para acelerar la búsqueda y aumentar nuestro rendimiento de base de datos. En el almacén de datos, usted tiene que hacer al menos un índice por tipo (será automáticamente generate, le guste o no) porque almacén de datos de búsqueda de su entidad sobre la base de estos índices y créanme que es la mejor parte, en el RDBMS puede realizar búsquedas con campo sin índice, aunque tomará algo de tiempo, pero lo hará. En Datastore no puede buscar utilizando propiedades que no sean de índice.

Conde
En RDMBS, es mucho más fácil contar (*) pero en almacén de datos, por favor, no siquiera pensar en forma normal (Sí hay una función de conteo), ya que tiene 1000 Limit y va a costar tanto small opertion como la entidad que no es buena, pero siempre tenemos buenas opciones, podemos usar Shard Counters.

Unique Constraints
En RDMBS, Nos encanta esta característica no? pero Datastore tiene su propio camino. no se puede definir una propiedad como :(único.

consulta
GAE Datatore proporciona una función mejor tanto LIKE (Oh no! almacén de datos no tienen como palabra clave) de SQL que es GQL.

Insert Data/Actualizar/eliminar/Seleccionar
Este donde todos nos interesa, como en RDMBS se requiere una consulta para insertar, actualizar, eliminar y seleccione al igual que RDBMS, almacén de datos ha puesto, borrar, obtener (no te dan demasiado excitado), porque Datastore poner u obtener en términos de Write, Read, Small Operations (Leer Costos para las llamadas al Almacén de datos) y es allí donde entra en acción el Modelado de datos. debes minimizar estas operaciones y mantener tu aplicación en funcionamiento. Para Reducir Read operation puede usar Memcache.

Answer 8

La manera en que veo es almacén de datos, tipo identifica mesa, per se, y la entidad es fila individual dentro de la tabla. Si google fuera a sacar algo bueno de lo que es solo una gran tabla sin estructura y puedes volcar lo que quieras en una entidad. En otras palabras, si las entidades no están ligadas a un tipo, usted puede tener cualquier estructura para una entidad y almacenar en una ubicación (como un gran archivo sin estructura, cada línea tiene su propia estructura).

Ahora, de vuelta al comentario original, Google Bigtable almacén de datos y son dos cosas diferentes, así que no confundir google almacén de datos al sentido de almacenamiento de datos del almacén de datos. Bigtable es más caro que bigquery (razón principal por la que no fuimos). Bigquery tiene uniones apropiadas y RDBMS como el lenguaje sql y es más barato, ¿por qué no utilizar bigquery? Dicho esto, bigquery tiene algunas limitaciones, dependiendo del tamaño de sus datos, puede que los encuentre o no.

Asimismo, en términos de pensar en términos de almacén de datos, creo que la declaración apropiado habría sido "pensando en términos de bases de datos NoSQL". Hay muchos disponibles en estos días, pero cuando se trata de productos de google, excepto google cloud SQL (que es mySQL), todo lo demás es NoSQL.