Te doy la bienvenida a nuestra comunidad, ahora encontrarás la solucíon de lo que necesitas.
Solución:
Definitivamente es mucho, mucho más lento que MySQL (para un servidor) o SQLite (para un cliente) que son preferibles.
Además, la velocidad de JSON depende casi exclusivamente de la implementación. Por ejemplo, podrías eval() , pero no solo es muy arriesgado, también es más lento que un analizador real. En cualquier caso, probablemente haya analizadores XML mucho mejor optimizados que los analizadores JSON, solo porque es un formato más utilizado. (Así que tome un XML del tamaño de un GB e imagine los mismos resultados pero más lento).
En serio, JSON nunca fue diseñado para grandes cosas. Utilice una base de datos real si es posible.
Editar: ¿por qué JSON es mucho más lento que una base de datos?
Muchas razones. Intentaré enumerar algunos.
- JSON se basa en secciones coincidentes como
s (muy parecido a XML<>s)
Esto significa que un analizador tiene que comprobar dónde está el final de un bloque de objeto. Hay otros de estos como []arena ""s. En una base de datos convencional, no hay “etiqueta de finalización” ni “corchete de finalización”, por lo que es más fácil de leer.
- Los analizadores JSON necesitan leer todos y cada uno de los caracteres antes de poder comprender la estructura completa del objeto.
Entonces, antes de que pueda leer algo del JSON, debe leer el archivo completo. Esto significa esperar unos minutos en el mejor de los casos para los tamaños que mencionó, y una base de datos está lista para ser consultada en menos de un segundo (porque la jerarquía se almacena al principio).
- En JSON no puede calcular previamente las compensaciones.
En una base de datos, el tamaño se intercambia por el rendimiento. Puedes hacer VARCHAR(512) y todas las cuerdas serán null-ajustado para ocupar 512 bytes. ¿Por qué? Porque de esa manera puede saber que el cuarto valor está en la compensación 2048, por ejemplo. No puede hacer eso con JSON, por lo tanto, el rendimiento se ve afectado.
- JSON está optimizado para archivos pequeños.
… Porque es un formato web.
Esto puede parecer un profesional, pero es una estafa desde la perspectiva del desempeño.
- JSON es un subconjunto de JavaScript.
Por lo tanto, algunos analizadores pueden permitir que estén presentes y considerados datos innecesarios, como los comentarios. El JSON nativo de Chrome solía permitir comentarios, por ejemplo (ya no).
Ningún motor de base de datos utiliza eval() ¿derecho?
- JSON está destinado a tener cierta resistencia a errores.
La gente puede poner cualquier cosa en un archivo JSON, por lo que los analizadores están a la defensiva e intentan leer archivos no válidos a veces. No se supone que la base de datos repare un archivo roto en silencio.
¡Puede codificar manualmente un JSON pero no una base de datos!
- JSON es un formato nuevo, no compatible y mal probado
Hay errores en algunos analizadores nativos (como IE8) y la compatibilidad con la mayoría de los navegadores es muy preliminar y más lenta que, digamos, el analizador XML más rápido que existe. Simplemente porque XML se ha utilizado durante años y Steve Ballmer tiene un fetiche XML, por lo que las empresas lo complacen al hacer que casi cualquier cosa bajo el sol sea compatible con XML. Mientras que JSON es uno de los pasatiempos de fin de semana exitosos de Crockford.
- Los mejores analizadores JSON están en los navegadores
Si elige un analizador JSON aleatorio de código abierto para su idioma favorito, ¿qué posibilidades hay de que sea el mejor analizador posible bajo el sol? Bueno, para XML tienes analizadores increíbles como este. Pero, ¿qué hay para JSON?
¿Necesita más razones por las que JSON debería relegarse a su caso de uso previsto?
Los puntos de referencia de JSON, XML y muchas otras cosas se pueden encontrar en el proyecto de serializadores de JVM. Los resultados son demasiado complicados para reproducirlos aquí, pero los mejores resultados JSON (comparando clases manuales y vinculadas a datos) son bastante mejores que los mejores resultados XML. Esa comparación no está completa, pero es un punto de partida.
EDITAR: a partir de ahora (2012-10-30), no hay resultados publicados, porque se está revisando el punto de referencia. Sin embargo, hay algunos resultados preliminares disponibles.
Si considera JSON como un formato intermedio para la transferencia de datos, es posible que también desee considerar alternativas binarias, ya que necesitan menos espacio en disco y ancho de banda de red (tanto comprimido como sin comprimir), por lo que puede obtener un análisis más rápido porque la entrada para analizar es corto.
- MessagePack
- BSON (JSON binario)
- Búferes de protocolo de Google
- Apache y Facebook Thrift
- Python Pickle implementado como el módulo `cPickle ‘con la versión más alta
- Python Marshal (muy rápido pero dependiente de la arquitectura y la versión)
Si ejecuta su propio punto de referencia, asegúrese de comparar varios analizadores para el mismo lenguaje, por ejemplo, se espera que un analizador JSON implementado en Python puro sea mucho más lento que un analizador JSON escrito en C, pero puede encontrar una diferencia de velocidad significativa ( hasta un factor de 2, pero quizás 5) entre diferentes implementaciones en el mismo lenguaje de programación también.