database - how - ¿Cómo pensar en almacenes de datos en lugar de bases de datos?
ndb google app engine (8)
Como ejemplo, Google App Engine utiliza Google Datastore, no una base de datos estándar, para almacenar datos. ¿Alguien tiene alguna sugerencia para usar Google Datastore en lugar de 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 Google Datastore (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 Google Datastore o BigTable tiene algún buen consejo para trabajar con ellos?
Eche un vistazo a la documentación de Objectify. El primer comentario en la parte inferior de la página dice:
"Es bueno, 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 en mi vida. Gracias".
Hay dos cosas principales a las que debe 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 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.
- La consulta, como lo aludió, es mucho más limitada. 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 absorbido 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 en que representa los 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. Aquí hay un recetario completo de este tipo de consejos y trucos. Editar: El libro de recetas ya no existe.
La forma en que he estado trabajando en el cambio de mentalidad es olvidarme por completo de la base de datos.
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 deberían duplicarse, 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 olvidarme de las bases de datos y simplemente crear una aplicación. Hasta el momento, he hecho 4 aplicaciones de App Engine usando esta filosofía y aún quedan más.
La forma en que veo el almacén de datos es, tipo identifica tabla, 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 volviendo al comentario original, google datastore y bigtable son dos cosas diferentes, así que no confunda el datastore de google con el almacenamiento de datos del datastore. 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.
Además, en términos de pensar en términos de almacén de datos, creo que la declaración correcta habría sido "pensar 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.
Si estás 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 algo parecido a uniones, puede ver las propiedades de referencia . No necesita preocuparse si usa BigTable para el servidor o algo más, ya que las interfaces GQL y Datastore API abstraen el backend.
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 externa específica 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()
Siendo enraizado en el mundo de las bases de datos, un data store 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 de bigtable: http://en.wikipedia.org/wiki/BigTable )
Vengo del mundo de las bases de datos relacionales y luego encontré esta cosa del Almacén de datos. tomó varios días para entenderlo. Bueno, hay algunos de mis hallazgos.
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 DataStore
Estructura
En la base de datos, generalmente estructuramos nuestros datos en Tablas, Filas que están en Datastore, se convierte en Tipos y Entidades .
Relaciones
En RDBMS, la mayoría de las personas cumple con la relación One-to-One, Many-to-One, Many-to-Many, en Datastore, ya que tiene la opción "No Joins" pero aún podemos lograr nuestra normalización usando " ReferenceProperty " Ejemplo de relación uno-a-uno .
Indexes
Por lo general, en RDMBS hacemos índices como clave principal, clave externa, clave única e índice para acelerar la búsqueda y aumentar el rendimiento de nuestra base de datos. En el almacén de datos, debe crear al menos un índice por tipo (generará automáticamente si le gusta o no) porque el almacén de datos busca en su entidad sobre la base de estos índices y créame que esa es la mejor parte, en RDBMS puede buscar usando campo sin índice, aunque tomará algo de tiempo, pero lo hará. En Datastore no 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, por favor ni siquiera lo piense de manera normal (sí, hay una función de conteo) ya que tiene un límite de 1000 y costará la operación más pequeña que la entidad que es no es bueno, pero siempre tenemos buenas opciones, podemos usar contadores de Shard .
Restricciones únicas
En RDMBS, nos encanta esta característica, ¿verdad? pero Datastore tiene su propio camino. no puede definir una propiedad como única :(.
Consulta
GAE Datatore proporciona una mejor característica, mucho LIKE (Oh no! Datastore no tiene la palabra clave LIKE) SQL que es GQL .
Insertar datos / Actualizar / Eliminar / Seleccionar
Aquí donde todos estamos interesados, como en RDMBS, necesitamos una consulta para Insertar, Actualizar, Eliminar y Seleccionar al igual que RDBMS, Datastore ha puesto, borrado, obtenido (no se entusiasma demasiado) porque Datastore puso u obtiene en términos de escritura, Lectura, Operaciones pequeñas (Leer los costos de las llamadas al Almacén de datos ) y es allí donde el Modelado de datos entra en acción. debes minimizar estas operaciones y mantener tu aplicación en funcionamiento. Para la operación de reducción de lectura , puede usar Memcache .