¿Qué base de datos debo usar para almacenar registros y cómo debo usarlos?

Question

Estoy desarrollando una aplicación que almacenará una cantidad considerable de registros. Estos registros serán algo así como (URL, fecha, título, fuente, {datos opcionales ...})

Como esta es una aplicación del lado del cliente, no quiero usar un servidor de base de datos, solo quiero la información almacenada en los archivos.

Quiero que los archivos sean legibles desde varios idiomas (al menos Python y C++), por lo que algo específico del lenguaje como el pepinillo de pitón está fuera del juego.

Estoy viendo dos posibilidades: sqlite y BerkeleyDB. Como mi caso de uso claramente no es relacional, estoy tentado de ir con BerkeleyDB, sin embargo, no sé cómo debería usarlo para almacenar mis registros, ya que solo almacena pares clave/valor.

¿Mi razonamiento es correcto? Si es así, ¿cómo debo usar BDB para almacenar mis registros? ¿Puedes vincularme a información relevante? ¿O estoy perdiendo una mejor solución?

Answer 1

Estoy viendo dos posibilidades: sqlite y BerkeleyDB. Como mi caso de uso es claramente no relacional, estoy tentado para ir con BerkeleyDB, sin embargo no sé realmente sé cómo debo usarlo para almacenar mis registros, ya que solo almacena pares de clave/valor.

Lo que está describiendo es exactamente de lo que se trata la relación, incluso si solo necesita una tabla. SQLite probablemente hará esto muy fácil de hacer.

EDITAR: El modelo relacional no tiene nada que ver con las relaciones entre tablas. Una relación es un subconjunto del producto cartesiano de otros conjuntos. Por ejemplo, el producto cartesiano de los Números Reales, Números Reales y Números Reales (Sí, los tres son lo mismo) producen espacio de coordenadas 3d, y usted podría definir una relación sobre ese espacio con una fórmula, digamos x*y = z. cada posible conjunto de coordenadas (x0,y0,z0) están en la relación si satisfacen la fórmula dada, o si no lo están.

Una base de datos relacional utiliza este concepto con algunos requisitos adicionales. Primero, y lo más importante, el tamaño de la relación debe ser finito. La relación de producto dada anteriormente no satisface ese requisito, porque hay infinitamente muchas 3-tuplas que satisfacen la fórmula.Hay varias otras consideraciones que tienen más que ver con lo que es práctico o útil en las computadoras reales que resuelven problemas reales.

Una mejor forma de pensar sobre el problema es pensar dónde cada tipo de mecanismo de persistencia funciona mejor que el otro. Ya reconoce que una solución relacional tiene sentido cuando tiene muchos conjuntos de datos separados (tablas) que deben admitir las relaciones entre ellos (restricciones de clave externa), que es casi imposible de aplicar con un almacén de clave-valor. Otra ventaja real de relacional es la forma en que hace posibles consultas ricas y ad-hoc con el uso de índices apropiados. Esto es una consecuencia de que la capa de la base de datos realmente comprenda los datos que está representando.

Una tienda de valores clave tiene su propio conjunto de ventajas. Una de las más importantes es la forma en que las tiendas de valores clave se escalan. No es necesario que memcached, couchdb, hadoop utilicen el almacenamiento de clave-valor, ya que es fácil distribuir la búsqueda de valores-clave en varios servidores. Otra área en la que el almacenamiento de clave-valor funciona bien es cuando la clave o el valor es opaco, como cuando el elemento almacenado está encriptado, solo para ser leído por su propietario.

---

Para entender este punto, que una base de datos relacional funciona bien incluso cuando simplemente no necesita más de una tabla, tenga en cuenta lo siguiente (no originales)

SELECT t1.actor1 
FROM workswith AS t1, 
    workswith AS t2, 
    workswith AS t3, 
    workswith AS t4, 
    workswith AS t5, 
    workswith AS t6 
WHERE t1.actor2 = t2.actor1 AND 
     t2.actor2 = t3.actor1 AND 
     t3.actor2 = t4.actor1 AND 
     t4.actor2 = t5.actor1 AND 
     t5.actor2 = t6.actor1 AND 
     t6.actor2 = "Kevin Bacon"; 

Lo cual, obviamente, utiliza una sola tabla: workswith para calcular cada actor con un número de tocino de 6

Answer 2

¿Qué hay de MongoDB? No lo he intentado todavía, pero parece interesante.

Answer 3

BerkeleyDB es bueno, también mira las encarnaciones * DBM (por ejemplo, GDBM). La gran pregunta es: ¿para qué necesitas buscar? ¿Necesita buscar por esa URL, por un rango de URL o las fechas que enumera?

También es muy posible mantener grupos de registros como archivos simples en el sistema de archivos local, agrupados por fechas o términos de búsqueda, & c.

Respondiendo a la pregunta de "búsqueda" es el mayor comienzo.

En cuanto a la clave/valor, lo que necesita asegurarse es que la CLAVE esté bien definida en cuanto a sus búsquedas. Si, por ejemplo, necesita buscar fechas a veces y otras por título, necesitará mantener una fila de "registro", y luego posiblemente 2 o más filas de "índice" haciendo referencia al registro original. Puede modelar casi cualquier cosa en un almacén de claves/valores.

Answer 4

Personalmente, utilizaría sqlite de todos modos. Siempre me ha funcionado (y para otros con los que trabajo). Cuando su aplicación crezca y de repente quiera hacer algo un poco más sofisticado, no tendrá que volver a escribir.

Por otro lado, he visto varios comentarios en la lista de desarrollo de Python sobre Berkely DB que sugieren que es menos que maravilloso; solo obtiene acceso estilo dict (lo que si desea seleccionar ciertos rangos de fechas o títulos en lugar de URL); y ni siquiera está en el conjunto estándar de bibliotecas de Python 3.

Answer 5

Si solo va a utilizar un solo campo para buscar registros, un simple almacén de valores-clave sería una buena opción. Almacene ese campo individual (o cualquier otro ID único) como su clave, serialice cada registro como una cadena (usando JSON o similar) y almacene esa cadena como el valor. Berkeley DB es sin duda una opción razonable para un almacén de claves-valor, pero hay muchas alternativas para elegir: http://en.wikipedia.org/wiki/Dbm

Si desea buscar registros por cualquiera de varios campos, SQLite podría ser más fácil para fines de desarrollo. Escribirá consultas en SQL pero no tendrá que mantener un servidor de base de datos. Toda la maquinaria multi-clave ya está escrita para usted.

Si realmente quiere evitar SQL o exprimir cada gota de rendimiento de su almacén de datos, y desea tener acceso multi-clave, considere una capa de la lógica extra en la parte superior de un almacén de claves-valor. Es posible construir un comportamiento similar a una columna sobre almacenes de clave-valor serializando sus registros e insertando los valores de "columna" de cada registro como claves adicionales cuyos valores contienen la clave "primaria" de su registro. (En realidad, está utilizando el almacén de valores-clave como un diccionario de registros y un diccionario de índices para encontrar esos registros). App Engine de Google hace algo como esto. Puede hacerlo usted mismo o utilizar una de las diversas bases de datos orientadas a documentos que lo harán por usted. Para algunas lecturas interesantes, prueba google "nosql". http://www.google.com/search?&q=nosql

Answer 6

Bien, entonces dices simplemente almacenando los datos ...? Realmente solo necesita una base de datos para recuperar, buscar, resumir, etc. Por lo tanto, para almacenar, simplemente use archivos de texto simples y añada líneas. Comprima los datos si lo necesita, use delims entre los campos; casi cualquier idioma podrá leer dichos archivos. Si desea recuperar, entonces concéntrese en sus necesidades de recuperación, por fecha, por clave, qué claves, etc. Si desea un lado del cliente simple, entonces necesita una base de datos de cliente simple. SQLite es mucho más fácil que BDB, pero mira cosas como Sybase Advantage (muy rápido y gratuito para clientes locales pero no de código abierto) o VistaDB o Firebird ... pero todos requerirán configuración/configuración/mantenimiento local. Si va a XML local para una cantidad "considerable" de registros, obtendrá algunos tamaños de archivo innecesariamente hinchados.