Hay formas de almacenar sus datos de texto de 10k pero si será aceptable dependerá de qué más necesite almacenar y cómo planea usarlo.
Si necesita almacenar datos arbitrariamente grandes (especialmente datos binarios), entonces el puntero del archivo S3 puede ser atractivo. El valor que SimpleDB agrega en este escenario es la capacidad de ejecutar consultas en contra de los metadatos del archivo que usted almacena en SimpleDB.
Para datos de texto limitados a 10k, recomendaría almacenarlos directamente en SimpleDB. Encajará fácilmente en un solo elemento, pero tendrá que extenderlo a través de múltiples atributos. Básicamente hay dos formas de hacer esto, cada una con algunos inconvenientes.
Una forma es más flexible y fácil de buscar pero requiere que toque sus datos. Divides tus datos en fragmentos de aproximadamente 1000 bytes y almacenas cada fragmento como un valor de atributo en un atributo de varios valores. No hay ordenamiento impuesto en atributos multivalor, por lo que debe anteponer cada fragmento con un número para ordenar (por ej. 01)
El hecho de tener todo el texto almacenado en un atributo hace que las consultas sean fáciles de hacer con un solo nombre de atributo en el predicado. Puede agregar un texto de diferente tamaño a cada elemento desde 1k hasta 200 + k y se maneja adecuadamente. Pero debe tener en cuenta que sus números de línea antepuestos pueden aparecer positivos para sus consultas (por ejemplo, si está buscando 01, cada elemento coincidirá con esa consulta).
La segunda forma de almacenar el texto dentro de SimpleDB no requiere que coloque datos de ordenamiento arbitrarios dentro de los fragmentos de texto. Usted hace el pedido colocando cada fragmento de texto en un atributo con nombre diferente. Por ejemplo, podría usar nombres de atributos: desc01desc02 ... desc10. Luego colocas cada pedazo en el atributo apropiado. Todavía puede hacer una búsqueda de texto completo con ambos métodos, pero las búsquedas serán más lentas con este método porque necesitará especificar muchos predicados y SimpleDB terminará buscando a través de un índice separado para cada atributo.
Puede ser fácil pensar en este tipo de trabajo como un truco porque con las bases de datos estamos acostumbrados a que este tipo de detalles de bajo nivel se manejen para nosotros dentro de la base de datos. SimpleDB está específicamente diseñado para llevar este tipo de cosas fuera de la base de datos y al cliente como un medio para proporcionar disponibilidad como una característica de primera clase.
Si descubrió que una base de datos relacional estaba dividiendo su texto en 1k fragmentos para almacenar en el disco como un detalle de implementación, no parecería un hack. El problema es que el estado actual de los clientes SimpleDB es tal que tiene que implementar mucho de este tipo de formato de datos usted mismo. Este es el tipo de cosa que idealmente se manejará para usted en un cliente inteligente.Simplemente no hay clientes inteligentes disponibles de forma gratuita todavía.
¿Cuáles son sus requisitos para recuperar los datos? ¿Tienes que buscar en él, separarlo por campos, etc.? – Mark
Solo necesito mostrar los datos de texto. Planeo etiquetar estos datos para poder consultarlos y mostrar al usuario el texto que tiene más de 1024 bytes. Supongo que tendré información de ciudad/estado/descripción y uno consultaría contra la ciudad y el estado y mostraría la descripción al usuario. –
Esto suena como un gran uso para SimpleDB. Solo necesita agregar una rutina para dividir el texto cuando almacena el elemento, y otro para volver a armarlo a partir de sus resultados seleccionados. "SELECT desc FROM Domain001 donde city =? INTERSECTION state =?" – Mocky