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

Question

Por ejemplo, Google App Engine utiliza Google Datastore, no una base de datos estándar, para almacenar datos.¿Alguien tiene algún consejo para utilizar Google Datastore en lugar de bases de datos?Parece que he entrenado mi mente para pensar al 100% en relaciones de objetos que se asignan directamente a las estructuras de las tablas, y ahora es difícil ver algo diferente.Puedo comprender algunos de los beneficios de Google Datastore (p. ej.rendimiento y la capacidad de distribuir datos), pero se sacrifica alguna buena funcionalidad de la base de datos (p. ej.Uniones).

¿Alguien que haya trabajado con Google Datastore o BigTable tiene algún buen consejo para trabajar con ellos?

Answer 1

Hay dos cosas principales a las que hay que acostumbrarse sobre el almacén de datos de App Engine en comparación con las bases de datos relacionales "tradicionales":

• El almacén de datos no hace distinción entre inserciones y actualizaciones.Cuando llamas a put() en una entidad, esa entidad se almacena en el almacén de datos con su clave única y todo lo que tenga esa clave se sobrescribe.Básicamente, cada tipo de entidad en el almacén de datos actúa como un mapa enorme o una lista ordenada.
• La consulta, como usted mencionó, es mucho más limitada.Para empezar, no hay uniones.

Lo clave a tener en cuenta (y la razón detrás de ambas diferencias) es que Bigtable básicamente actúa como un enorme diccionario ordenado.Por lo tanto, una operación de venta simplemente establece el valor de una clave determinada, independientemente de cualquier valor anterior para esa clave, y las operaciones de recuperación se limitan a recuperar claves individuales o rangos contiguos de claves.Las consultas más sofisticadas son posibles con índices, que son básicamente tablas propias, lo que le permite implementar consultas más complejas como escaneos en rangos contiguos.

Una vez que haya absorbido eso, tendrá los conocimientos básicos necesarios para comprender las capacidades y limitaciones del almacén de datos.Las restricciones que podrían haber parecido arbitrarias probablemente tengan más sentido.

La clave aquí es que, aunque estas son restricciones sobre lo que se 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 para la que Bigtable está diseñado para manejar.Simplemente no se puede ejecutar el tipo de consulta que se ve bien en papel pero que es terriblemente lenta en una base de datos SQL.

En términos de cómo cambiar la forma de representar los datos, lo más importante es el cálculo previo.En lugar de realizar uniones en el momento de la consulta, calcule previamente 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 guárdelo con cada registro. Hay un libro de cocina completo con este tipo de consejos y trucos. aquí Editar:El libro de cocina ya no existe.

Answer 2

La forma en que he estado abordando el cambio de mente es olvidándome por completo de la base de datos.

En el mundo de las bases de datos relacionales, siempre hay que preocuparse por la normalización de los datos y la estructura de la tabla.Deshazte de todo.Simplemente diseñe su página web.Extiéndelos todos.Ahora míralos.Ya estás 2/3 allí.

Si olvida la noción de que el tamaño de la base de datos importa y que los datos no deben duplicarse, entonces estará 3/4 allí y ni siquiera tuvo que escribir ningún código.Deje que sus puntos de vista dicten sus modelos.Ya no tienes que tomar tus objetos y hacerlos bidimensionales como en el mundo relacional.Puedes almacenar objetos con forma ahora.

Sí, esta es una explicación simplificada de la terrible experiencia, pero me ayudó a olvidarme de las bases de datos y simplemente hacer una solicitud.Hasta ahora he creado 4 aplicaciones de App Engine usando esta filosofía y hay más por venir.

Answer 3

Siempre me río entre dientes cuando la gente dice: no es relacional.Escribí cellectr en django y aquí hay un fragmento de mi modelo a continuación.Como verás, tengo ligas que son administradas o dirigidas por usuarios.Puedo obtener de una liga a todos los entrenadores, o de un usuario determinado puedo devolver la liga que entrena o dirige.

El hecho de que no exista soporte específico para claves externas no significa que no se 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 4

Vengo del mundo de las bases de datos relacionales y luego encontré esto del almacén de datos.Me llevó varios días acostumbrarme.Bueno, ahí están algunos de mis hallazgos.

Ya debes saber que Datastore está diseñado para escalar 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, normalmente estructuramos nuestros datos en tablas, filas que están en el almacén de datos y se convierten en Clases y entidades.

Relaciones
En RDBMS, la mayoría de la gente sigue la relación uno a uno, muchos a uno, muchos a muchos, en Datastore, ya que tiene "No hay uniones", pero aún así podemos lograr nuestra normalización usando "Propiedad de referencia" p.ej. Ejemplo de relación uno a uno .

Índices
Por lo general, en RDMBS creamos índices como clave primaria, clave externa, clave única y clave de índice para acelerar la búsqueda y mejorar el rendimiento de nuestra base de datos.En el almacén de datos, debe crear al menos un índice por tipo (automáticamente generar le guste o no) porque el almacén de datos busca su entidad en función de estos índices y créame, esa es la mejor parte. En RDBMS puede buscar utilizando campos que no son de índice, aunque llevará algún tiempo, pero lo hará.En Datastore no se puede buscar utilizando propiedades que no sean de índice.

Contar
En RDMBS, es mucho más fácil contar (*), pero en el almacén de datos, ni siquiera lo piense de manera normal (Sí, hay una función de conteo), ya que tiene Límite de 1000 y costará tanto pequeña operación como entidad que no es buena pero siempre tenemos buenas opciones, podemos usar Contadores de fragmentos.

Restricciones únicas
En RDMBS, nos encanta esta función, ¿verdad?pero Datastore tiene su propio camino.no puedes definir una propiedad como única :(.

Consulta
GAE Datatore proporciona una característica mucho mejor COMO(¡Oh, no!el almacén de datos no tiene la palabra clave LIKE) SQL que es GQL.

Insertar datos/Actualizar/Eliminar/Seleccionar
Esto es lo que nos interesa a todos, ya que en RDMBS requerimos una consulta para Insertar, Actualizar, Eliminar y Seleccionar, al igual que RDBMS, Datastore ha puesto, eliminado y obtenido (no se emocione demasiado) porque Datastore puso u obtuvo en términos de Escribir, leer, pequeñas operaciones(Leer Costos de llamadas al almacén de datos) y ahí es donde entra en acción el modelado de datos.debe minimizar estas operaciones y mantener su aplicación en funcionamiento.Para reducir Leer operación puedes usar Memcache.

Answer 5

Eche un vistazo a la documentación de Objectify.El primer comentario al final de la página dice:

"Bien, aunque escribiste esto para describir Objectify, también es una de las explicaciones más concisas del almacén de datos de appengine que he leído.Gracias."

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

Answer 6

Si está acostumbrado a pensar en entidades asignadas por ORM, así es básicamente como funciona un almacén de datos basado en entidades como App Engine de Google.Para algo como uniones, puedes mirar propiedades de referencia.Realmente no necesita preocuparse por si usa BigTable para el backend o algo más, ya que el backend está abstraído por las interfaces GQL y Datastore API.

Answer 7

La forma en que veo el almacén de datos es que el tipo identifica la tabla, per se, y la entidad es una fila individual dentro de la tabla.Si Google eliminara el tipo, sería solo una tabla grande sin estructura y puedes volcar lo que quieras en una entidad.En otras palabras, si las entidades no están vinculadas a un tipo, prácticamente puede tener cualquier estructura para una entidad y almacenarla en una ubicación (una especie de archivo grande sin estructura, cada línea tiene su propia estructura).

Ahora, volviendo al comentario original, Google Datastore y Bigtable son dos cosas diferentes, así que no confunda Google Datastore con el sentido de almacenamiento de datos del almacén de datos.Bigtable es más caro que bigquery (la razón principal por la que no lo optamos).Bigquery tiene uniones adecuadas 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, es posible que las encuentre o no.

Además, en términos de pensar en términos de almacén de datos, creo que la afirmación correcta habría sido "pensar en términos de bases de datos NoSQL".Hay muchos de ellos disponibles hoy en día, pero cuando se trata de productos de Google, excepto Google Cloud SQL (que es MySQL), todo lo demás es NoSQL.

Answer 8

Al estar arraigado en el mundo de las bases de datos, para mí un almacén de datos 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, aun así, sigue siendo una base de datos.Lo más probable es que, a menos que sepa que necesita crear algo como la "mesa grande" de Google, probablemente estará bien con una base de datos estándar.Lo necesitan porque están manejando cantidades increíbles de datos y sistemas juntos, y ningún sistema disponible comercialmente puede realmente hacer el trabajo de la manera exacta en que pueden demostrar que necesitan que se haga el trabajo.

(referencia de tabla grande: http://en.wikipedia.org/wiki/BigTable)