google-app-engine - with - python google api search

¿Cuándo NO debo usar la API de búsqueda de texto completo de App Engine?

Question

Hasta ahora, he usado la búsqueda de texto completo de App Engine para ayudar a buscar a través de las entidades existentes en mi almacén de datos. Esto implica crear al menos un Document por entidad, y vincular los dos de alguna manera. Y cada vez que cambio la entidad, debo cambiar los Documents correspondientes.

Mi pregunta es, ¿por qué no solo almacenar todos mis datos en Documents y olvidarme de las entidades del almacén de datos? La API de búsqueda admite un lenguaje de consulta mucho más rico que puede manejar múltiples filtros de desigualdad y operadores booleanos, a diferencia del almacén de datos.

¿Me falta algo sobre el diseño de la API de búsqueda que impida utilizarlo para reemplazar el almacén de datos por completo?

Answer 1

Además de los costos de rendimiento para consultar grandes conjuntos de datos, el almacén de datos también tiene la ventaja de permitir datos muy consistentes. Eche un vistazo a este enlace para obtener más información sobre datos consistentes vs. datos consistentes eventuales.

Se debe asumir que los documentos almacenados en los índices de la API de búsqueda son finalmente consistentes .

Answer 2

En este momento, indizo una entidad en el searchdoc cada vez que la coloco y también indizo una versión serializada de la entidad.
en realidad es mucho más rápido buscar documentos en la API de búsqueda y extraer el campo serializado que obtener la misma cantidad de entidades del almacén de datos.

Answer 3

Según los documentos de Java.

Sin embargo, una búsqueda de índice no puede encontrar más de 10,000 documentos coincidentes. El almacén de datos de App Engine puede ser más apropiado para las aplicaciones que necesitan recuperar conjuntos de resultados muy grandes.

Aunque no lo veo como un caso de uso común.

De manera más realista, obtener entidades por clave será mucho más barato con el almacén de datos (presumiblemente también más rápido). Con la API de búsqueda, puede usar Index.get () para encontrar un documento por ID, o duplicar la ID almacenándola en un campo y buscando en ese campo.

Aquí hay un desglose de costos:

- Index.get():     $0.10 /  10,000 or 0.00001 per get
- Index.search():  $0.13 /  10,000 or 0.000013 per get
- Datastore get(): $0.06 / 100,000 or 0.0000006 per get

Como puede ver, un Datastore get es mucho más barato que las opciones de la API de búsqueda (16 veces más barato que Index.get ()).

Si sus datos están estructurados de una manera que hace uso de muchas aplicaciones directas y pocas búsquedas complejas, el almacén de datos será un claro ganador en términos de costo.

Nota: No incluí el costo adicional para almacenar datos duplicados con el método Index.search (), ya que eso depende de cuántas entidades almacene.

Answer 4

Simplemente coloque los datos en ambos: el almacenamiento es barato y, dependiendo de la cantidad de escrituras que haga su aplicación, también podría ser barato hacer actualizaciones. Para consultas sencillas y para obtener entidades individuales por clave, use memcache y el almacén de datos. Para consultas complejas utiliza la API de búsqueda. Tendrá que hacer la compensación una vez que se anuncie el precio.

Answer 5

Usted no:

1. perder cualquier beneficio de memcache

2. Se enfrentan a menores cuotas. "esperamos que nuestra cuota gratuita cubra alrededor de 1,000 búsquedas por día una vez que la función se haya graduado de experimental" No puedo ver la cantidad de lecturas que recibe, pero creo que es mayor para el almacén de datos. Miré https://developers.google.com/appengine/docs/quotas#Resources

   Además, para una actualización de entidad, se nos cobra de manera diferente por actualización o nueva venta. Parece que los índices no se actualizan sino que se agregan como un nuevo documento (eso es lo que estoy haciendo de todos modos). Al no tener los detalles del precio del índice, es difícil saberlo con exactitud, pero tal vez actualizar uno o dos valores indexados en una entidad sería más barato que poner un nuevo índice completo. Dependería de tus datos, supongo.

   Finalmente, el tamaño total del índice para los índices ahora está a 250M, mientras que los datos están limitados a 1 GB. El almacén de datos es más grande en ese momento y aún no hay información sobre los costos de fijación de precios adicionales para el índice.

3. Necesito idear un plan de respaldo. No sé de todos modos ahora para hacer una copia de seguridad o restaurar el índice si se corrompió. Tener los datos en entidades significa que se podría recrear el índice de búsqueda. Puede hacer una copia de seguridad con la consola de administración para el almacén de datos ahora.