Portada
mis comunidades
otras secciones
#3:
No entiendo que se vote irrelevante a un artículo de la sección de tecnología que habla de tecnología y que explica perfectamente el trabajo que se hizo y por qué. De lo más interesante que he leído en tiempo
#18:
#9 "Evitar el SQL"... necesito saber por qué debo evitar usar una tecnología que fue desarrollada para solventar de forma eficiente todos los problemas que plantea no usarla.
"Un paso atrás"... necesito saber por qué utilizar SQL es ir un paso atrás. NoSQL es un sistema cuyos casos de uso son tan restringidos que sinceramente no puedo tenerlo en cuenta para la práctica totalidad de proyectos en los que he trabajado los últimos 10 años, en clientes y en productos propios.
En cuanto los datos que tienes almacenados necesitan estar relacionados entre sí de alguna manera, vas a necesitar SQL. Y vas a necesitarlo porque las bases de datos relacionales se desarrollaron específicamente para eso y NoSQL no te ofrece nada más que un pozal donde meter tus datos y luego relaciónalos tú en el código o utiliza sus relaciones "wannabe" que no son ni una milésima parte de eficientes y consistentes que SQL.
Que las universidades estén enseñando que MongoDB es "la panacea" y que usar SQL es "ir hacia atrás" es bastante preocupante y esos profesores deberían ser primero azotados en el propio campus y luego despojados de sus títulos y expulsados del país. Que se vayan a buscar startups por Londres o por Sanfransisco a quienes venderles su humo y que cuenten sus chorradas en Medium. En las empresas serias y en la academia, por favor quiero soluciones reales y la herramienta adecuada para cada trabajo. MongoDB puede ser una solución para un determinado rango de problemas, pero ni de coña es una solución para la inmensa mayoría de situaciones de almacenamiento de datos como SQL (que por cierto también serviría para hacer lo mismo que Mongo).
"Un paso atrás"... necesito saber por qué utilizar SQL es ir un paso atrás. NoSQL es un sistema cuyos casos de uso son tan restringidos que sinceramente no puedo tenerlo en cuenta para la práctica totalidad de proyectos en los que he trabajado los últimos 10 años, en clientes y en productos propios.
En cuanto los datos que tienes almacenados necesitan estar relacionados entre sí de alguna manera, vas a necesitar SQL. Y vas a necesitarlo porque las bases de datos relacionales se desarrollaron específicamente para eso y NoSQL no te ofrece nada más que un pozal donde meter tus datos y luego relaciónalos tú en el código o utiliza sus relaciones "wannabe" que no son ni una milésima parte de eficientes y consistentes que SQL.
Que las universidades estén enseñando que MongoDB es "la panacea" y que usar SQL es "ir hacia atrás" es bastante preocupante y esos profesores deberían ser primero azotados en el propio campus y luego despojados de sus títulos y expulsados del país. Que se vayan a buscar startups por Londres o por Sanfransisco a quienes venderles su humo y que cuenten sus chorradas en Medium. En las empresas serias y en la academia, por favor quiero soluciones reales y la herramienta adecuada para cada trabajo. MongoDB puede ser una solución para un determinado rango de problemas, pero ni de coña es una solución para la inmensa mayoría de situaciones de almacenamiento de datos como SQL (que por cierto también serviría para hacer lo mismo que Mongo).
#7:
Voy a opinar, pero advierto que contra MongoDB no soy objetivo:
Todo lo que sea quitar MongoDB es un bien para la humanidad.
Todo lo que sea quitar MongoDB es un bien para la humanidad.
Comentarios
No entiendo que se vote irrelevante a un artículo de la sección de tecnología que habla de tecnología y que explica perfectamente el trabajo que se hizo y por qué. De lo más interesante que he leído en tiempo
#3
Porque si no viene de Xataka no interesa.
#4 O no se entiende.
#5
Lo que viene a ser exactamente lo mismo. Menéame está en niveles Xatakamierder para llegar a portada del general.
#3 "Cazadores de carma", en cuanto huelen la sangre en portada, se tiran a por sus "puntos". ¿No hay una política que penalice el "farmeo" en menéame?
#3 Bueno a mi no me parece un buen artículo por lo que comento en #20, pero lo voté positivo porque me gustaría que hubiera debate, pero ya veo que si no es de la misma mierda política o sensacionalista de siempre aquí no llega a portada nada.
#22 a mi me parece interesante porque explican el proceso desde que se dan cuenta de que ha sido una metedura de pata y como hicieron para superar el problema
#3 La verdad es que es un articulazo.
Explican los problemas que tenían... los motivos que les llevan a migrar... y encima si lo sumas a "por qué se fueron a Mongo" diría que han tenido bastante mal asesoramiento en el pasado.
No es el primer caso de negocio que conozco que sucumbe a una moda. La época de la migración a MongoDB es la época en la que se hablaba que las NoSQL iban a matar a las relacionales porque se podía hacer lo mismo que en ellas pero encima no tenías esquema o éste era mucho más rígido. Una mentira tremenda pero sostenida durante años.
Han tardado por lo menos 5 años en comprender que cada base de datos tiene su uso . Yo he llegado a ver una base de datos relacional montada sobre Elasticsearch...
Relacionado con ésto... recomendaría el post de Discord sobre sus BBDDs: https://blog.discordapp.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7
#28 Bueno, sobre el papel Mongo es una elección válida para un periódico cuyas noticias no deberían tener muchas relaciones. Diría que su principal problema vino por el lado cloud y aparte había algunas limitaciones técnicas para lo que ellos querían.
De todas formas, yo tampoco hubiera escogido una NoSQL para esto. Por mucho que deteste Postgre me parece una idea mucho más sensata utilizarla antes que Mongo. Mongo está bien para datos de auditoría y en general datos que no tengan una estructura demasiado homogénea y que además sean relativamente (o completamente) independientes entre sí. Por más novedosas que parezcan en realidad son bastante rústicas.
PD: Si algún jefazo de Mongo me lee... mi deseo para los reyes magos es que levantar un ReplicaSet en Docker via Ansible no sea un trabajo para Ethan Hunt, campeones.
#29
Yo no creo que viniera por el tema Cloud... yo repito creo que es un mal asesoramiento: AWS da muchas facilidades para algunas de las cosas que necesitaban y me parece como poco arriesgado meterse en el berenjenal que se metieron sin el asesoramiento de algún DBA en condiciones. Las noticias están estructuradas por temas, días, etiquetas, autores.... para mi eso te define una BBDD relacional de manual. La duda puede ser el sistema de comentarios... pero poco más. MongoDB soporta "relaciones" pero NADIE en Mongo te va a recomendar que la uses salvo que sea tu último recurso.
Según mi experiencia, la descripción de las limitaciones y los problemas que tenían les debía llevar a utilizar una base de datos relacional que soporte documentos (JSONs, etc) y que tenga capacidad de escalar. Vamos un PostgreSQL con réplicas de solo lectura
El miedo de las compañías a las bases de datos relacionales se basa en los problemas que se sufren con las modificaciones de esquema y su poca escalabilidad (cortes para mantenimiento y tal), pero es que si necesitas datos estructurados estás atado a ellas... Salvo que decidas utilizar Cloud Spanner*, (utilizada por Airbnb) siempre vas a estar atado a los límites matemáticos del teorema CAP.
Levantar un ReplicaSet en Docker con Ansible no es difícil, Google tiene hasta laboratorios públicos para ello... ¿Cual es el problema?
Nota 1: ¿ Por qué detestas PostgreSQL?
*Nota 2: Spanner es 99,95% C, 99,95% A y 99,95% P ... pero es carísimo
#30 Te respondo el día que vuelva por la ofi para darte datos un poco más concretos, pero parece imposible conseguir que levante sin hacer acciones manuales para crear el RS. Ahora mismo estamos planteándonos hacer un contenedor auxiliar que cree la estructura del master (usuarios, colecciones, etc) para que cuando se levanten los tres contenedores definitivos el master pueda iniciar la comunicación.
Hemos visto mogollón de ejemplos de cómo hacerlo pero siempre, siempre tiran de acciones manuales para inicializar por primera vez el sistema y lo que nos interesa es que un playbook levante todo sin intervención humana.
Tal vez no hemos dado con el ejemplo correcto (o peor, no lo hemos entendido), pero es una de mis tareas para estas navidades y me gustaría tenerla lista para cuando vuelva el resto de la gente
PD: Porque Postres en Mongo nos ha dado bastantes problemas a la hora de hacer ciertas configuraciones. Bendita versión 11, donde cosas que nos hicieron sudar sangre en versiones anteriores salieron a la primera.
Pedazo de artículo!!!
#1 este tipo de cosas deberían enseñarlas en la universidad... Un caso práctico o similar.
#1 #2 Pues tengo malas noticias: Esto se resumen en un "me dijeron de hacer A y que esto valia para A" me lo pase por el forro y no funciona como quiero. Hay un comentario en reddit enorme explicando todo, pero no he conseguido encontrarlo
#6 Aqui lo teneis los comentarios de /u/parck: https://old.reddit.com/r/scala/comments/a7t5rv/bye_bye_mongo_hello_postgres_switching_dbs_for/
#6 Venia a decir esto mismo, de hecho no se que esperan, que los problemas desaparezcan? se quejan de:
digo yo.. por qué migraron de oracle? porque los problemas que podrían tener con oracle los pueden tener con postgres exactamente igual (y oracle también tiene JSON como tipo de columna, que ya puestos..)
- Que el soporte era malo y llevar la BD ellos mismos es difícil. Ahora pasan a tener absolutamente ningún soporte con nadie y siguen llevando todo ellos.
- Que si configuran mal las cosas van mal (esto por lo de NTP y lo de su app generando indices y demás y tal) pues como con mongo con cualquier cosa, si haces cosas mal pasan cosas malas, a cualquiera le puede ocurrir, pero echar balones fuera es un problema aún mayor.
- Que antes usaban Oracle, pasaron a una bd de documentos y ahora usan una bd relacional con una columna jsonb
Por otra parte antes de publicar nada, yo haría un estudio o recolectaría algunos datos para ver como va, porque joder no me creo que empiecen con "bueno hemos puesto postgres y malo será! que el rendimiento debería ir bien!" pero wtf.. tanta prisa tenían por publicar esto? no podían poner benchmarks y cosas objetivas de por qué X es mejor que Y? va mejor? más rápido? es más eficiente? da menos problemas? algo con perspectiva y no una historieta de lo que acaban de hacer este fin de semana.
Que yo soy partidario como el que más da probar, cambiar y oye, cada uno que haga lo que quiera, pero si abren un artículo diciendo prácticamente que mongo es mierda que lo fundamenten un poco, a la gente nos interesan los casos reales pero con datos.
#20 Es posible que migraran de Oracle por los costes de soporte y licenciamiento.
https://www.oracle.com/assets/technology-price-list-070617.pdf
He visto implantar clusters de pocas maquinas en administraciones que salían por mas de 350k€ en licenciamiento.
Luego esta el soporte que es de los mas caros y su calidad es de lo mas normal.
Una cosa esta clara, administrar Oracle es mas complicado que Posgresql. La documentación y el CLI es infinitamente mejor en Postgresql.
Voy a opinar, pero advierto que contra MongoDB no soy objetivo:
Todo lo que sea quitar MongoDB es un bien para la humanidad.
#7 Si usas una base de datos específica, para algo que no está diseñada, o la usas de "manera creativa" tendrás problemas.
#7 ¿Por qué? ¿Acaso no conoces la persistencia políglota?
#7 Bien, pero ¿podrías argumentar? porque en realidad va un poco en la linea del artículo "bueno cambiamos porque ehmm hicimos cosas mal, montamos una infraestructura medio soportada en vez de la que ellos ofrecen, pero la culpa no es nuestra, es de mongo, mongo malo "
#19 Pues a lo mejor ha cambiado, pero cuando hicimos early adoption,
era mas lenta que el caballo del malo.
Bravo por lo de PostgreSQL y condolencias por usar Amazon RDS.
Una empresa como The Guardian puede permitirse tener su propio clúster redundante de almacenamiento y base de datos, aunque sea alquilando servidores en un centro de datos, no usando infraestructura propietaria como la de Amazon.
#10 No entiendo el porque de tu afirmación. Para la base de datos primaria donde trabajan los periodistas, puede tenir sentido lo que tu dices. Es una carga predecible y realmente poqueña. Ahora bien, para las proxys caches, donde se almacenan las copias que consultan los subscriptores viene muy bien poder provisionar servidores rapidamente, y poderlos repartir geograficamente todo el mundo ya que las consultas de las subscritores, puede variar mucho si un artículo se viraliza. Esos servidores solo los activas cuando los necesitas. Como el pago es por uso, no se malgastan recursos.
Manolete, si no sabes torear, pa qué te metes. Y encima admitiendo que no tienen zorra idea de bases de datos.. señor, llevame pronto...
Hay muchas empresas tipo startup que usan Mongo "porque es rápido" pero simplemente están empezando. Aparte que hay mucho brogrammer que les gusta usar la tecnología más cool y menos probada para sentirse guays.
Pero cuando la lógica de negocio se complica, la base de datos tiende a ser más relacional que documental, sin embargo la elección inicial (Mongo) se mantiene, y es cuando aparecen los problemas: que no sirve. Empiezan a duplicar documentos para no tener que hacer joins (muy lentos en Mongo), algo totalmente optimizado en Postgres. La hostia está asegurada.
Es curioso, porque en muchas universidades venden el MongoDB como la panacea, y evitar el SQL, y ahora van un paso atras.
Me recuerda a ingeniería informática, en el 2011 o así cuando estaba estudiando, en arquitectura de computadores estudiabamos procesadores de los años 90, obsoletos. Y eso que fui a una universidad de las que se consideran buenas en tecnología. Así que, sí, la universidad va un pasito pro detrás al sector.
#9 Para nada, ellos mismos dicen que estuvieron a punto de usar DynamoDB, que es Big data, y que lo rechazaron porque todavía no soportaba REST cifrado.
Sobre si les va a ir mejor postres que MongoDB, supongo que será porque hacen muchas consultas por otras claves (id y fecha del artículo) y pocas por el contenido, porque si no cuando vean cómo actúa postres buscando dentro del propio JSONB igual se arrepienten.
#9 Pero es que para entender un procesador actual no digo que tengas que aprender como funcionaban los de los 90, casi que me iría a los de los 70.
#9 "Evitar el SQL"... necesito saber por qué debo evitar usar una tecnología que fue desarrollada para solventar de forma eficiente todos los problemas que plantea no usarla.
"Un paso atrás"... necesito saber por qué utilizar SQL es ir un paso atrás. NoSQL es un sistema cuyos casos de uso son tan restringidos que sinceramente no puedo tenerlo en cuenta para la práctica totalidad de proyectos en los que he trabajado los últimos 10 años, en clientes y en productos propios.
En cuanto los datos que tienes almacenados necesitan estar relacionados entre sí de alguna manera, vas a necesitar SQL. Y vas a necesitarlo porque las bases de datos relacionales se desarrollaron específicamente para eso y NoSQL no te ofrece nada más que un pozal donde meter tus datos y luego relaciónalos tú en el código o utiliza sus relaciones "wannabe" que no son ni una milésima parte de eficientes y consistentes que SQL.
Que las universidades estén enseñando que MongoDB es "la panacea" y que usar SQL es "ir hacia atrás" es bastante preocupante y esos profesores deberían ser primero azotados en el propio campus y luego despojados de sus títulos y expulsados del país. Que se vayan a buscar startups por Londres o por Sanfransisco a quienes venderles su humo y que cuenten sus chorradas en Medium. En las empresas serias y en la academia, por favor quiero soluciones reales y la herramienta adecuada para cada trabajo. MongoDB puede ser una solución para un determinado rango de problemas, pero ni de coña es una solución para la inmensa mayoría de situaciones de almacenamiento de datos como SQL (que por cierto también serviría para hacer lo mismo que Mongo).
#18 ¿Sabes de lo que hablas? Primero comparar SQL con NoSQL no tiene sentido, lo primero es un lenguaje, lo segundo es un conjunto de bases de datos de diferentes tipos, soltar cosas como "En cuanto los datos que tienes almacenados necesitan estar relacionados entre sí de alguna manera, vas a necesitar SQL" es demostrar no tener ni idea. NoSQL incluye multitud de tipos de base de datos, no solo las documentales como MongoDB, algunas de ellas como las de grafos precisamente si son excelentes para una cosa lo son para las relaciones entre datos donde una base de datos relacional de "toda la vida" se ahoga de mala manera haciendo joins.
Por otra parte en las bases de datos documentales existen relaciones, lo que no es conveniente es que esas relaciones se hagan en forma de joins como una base de datos NoSQL. Me he encontrado montones de veces a gente intentando replicar la estructura y normalización de base de datos relacional a una documental, y eso es una barbaridad enorme. Duplicar datos, algo que según las reglas de normalización no debería hacerse es normal, irónicamente, en una base de datos documental, y los métodos de actualización que proporciona, que es donde el SQL necesita la normalización, están pensados para tratar con esas duplicaciones.
Para finalizar, los The Guardian migan a Postgres no a una base de datos relacional, porque Postgres también es una base de datos NoSQL de tipo documental como MongoDB mediante campos JSONB que es precisamente lo que están usando en The Guardian ya que la razón de la migración no es documental vs relacional, si no el coste de soportar MongoDB. Y precisamente esa es una gran característica de Postgres, que te permite estar en los dos mundos de forma prácticamente trivial manteniendo una sola infrastructura, sin tener que renunciar a ninguno de los dos tipos de almacenamiento de datos, entre otras muchas, por lo que yo siempre que puedo recomiendo usarla frente a otras como SQL Server u Oracle.