423 meneos
14112 clics
Stonebraker: la base de datos Oracle está obsoleta y Facebook tiene el mayor problema de datos del mundo
La leyenda viva del mundo de las bases de datos, Michael Stonebraker, comenta los problemas que en la actualidad tienen las bases de datos tradicionales y cual es el futuro según su opinión.
|
comentarios cerrados
Sin pararse a leer este punto clave:
Mi punto de vista es que si quieres realizar 50 transacciones por segundo, no importa qué tecnología utilices, puedes usar la que quieras. Pero si deseas ejecutar 50.000 transacciones por segundo, tu implementación actual simplemente no va a lograrlo
Es decir, que a no ser que tengas una carga brutal de datos, tanto en tamaño como en número de transacciones, Oracle o tecnologías parecidas te van a seguir siendo útiles. El problema lo tienen Facebook, Google y demás.
Ejemplo: www.meneame.net/c/12939269
Oracle, Microsoft e IBM solo tienen que ponerse las pilas y sacar su versión y casi 100% seguro que seguirán dominando el mercado.
Claro está esto es siempre que no se duerman en los laureles, si hacen como Microsoft con Explorer 6 al final lo que van a tener es un montón de clientes que se van a ir a la competencia. Hay que sacar un buen producto, pero tampoco puedes pasar siglos sin sacar la versión.
Sin pararse a leer este punto clave:
Mi punto de vista es que si quieres realizar 50 transacciones por segundo, no importa qué tecnología utilices, puedes usar la que quieras. Pero si deseas ejecutar 50.000 transacciones por segundo, tu implementación actual simplemente no va a lograrlo
Es decir, que a no ser que tengas una carga brutal de datos, tanto en tamaño como en número de transacciones, Oracle o tecnologías parecidas te van a seguir siendo útiles. El problema lo tienen Facebook, Google y demás.
Ejemplo: www.meneame.net/c/12939269
blogs.barrons.com/techtraderdaily/2015/03/30/michael-stonebraker-descr
...VU-FILE trabaja siempre con todos los registros en memoria...
www.teknoplof.com/2015/03/11/vu-file-una-base-de-datos-para-zx-spectru
BigTable y Spanner a nivel de usuario son basicamente iguales, solo cambia el backend. BigTable esta limitado a un datacenter y mientras que Spanner puede sincronizarse entre distintos datacenters.
research.google.com/archive/spanner.html
research.google.com/archive/bigtable.html
El problema es que si continuamos con el modelo tradicional de bases de datos solo saldrán adelante los grandes, al final el metal lo resuelve todo, y no me refiero solo al dinero, sino a los grandes procesadores, servidores y centros de datos.
También te digo que las alternativas (yo solo he probado MongoDB) tampoco son la panacea en cuanto al rendimiento. Pero si que simplifican mucho el diseño y el desarrollo y esto acerca a los pequeños desarrolladores a competir con Google o con Facebook.
www.themoderndaypirates.com/pirates/wp-content/uploads/2010/05/max-pow
en.wikipedia.org/wiki/List_of_in-memory_databases
Que otras aproximaciones para cierto tipo de datos o usos sean más eficientes, no lo pongo en duda. Pero es eso, para casos menos generales. Y como apuntan por ahí, las bases de datos relacionales tradicionales están tomando nota para poder cubrirlos.
www.mongodb.org/about/
No se si Facebook utiliza ya Hive para la serving, pero si lo esta utilizando, espero que lo utilice sobre Tez o Spark, ya que con MapReduce es mas lento que el caballo del malo a pata coja.
Además parece centrarse en el hecho de llevar la bdd completa a memoria principal dejándose por el camino los intentos que ha habido antes para dotar de herramientas orientadas a la mejora de rendimiento, en la fase de diseño, de determinadas operaciones usando, por ejemplo, almacenamiento columnal en lugar de guardando los registros en bruto como se menciona.
Por otro lado, Oracle (te caerá mejor o peor con el don que tiene para echar a perder productos que adquieren aparte de su SGBD) introdujo en 12cR1 la posibilidad de tener la parte de la BDD que tú quieras en memoria: blogs.oracle.com/In-Memory/entry/getting_started_with_oracle_database Por eso figura en las listas de "In-memory Databases" como menciona #33
IMHO, ni ha habido... ni hay... ni, posiblemente, habrá una herramienta que sirva para todo. No creo que sea cuestión de un paradigma desterrando a otro. Y si Oracle pretende convertir su SGBD en una especie de "anillo único" o lkanzará un producto independiente ya será cosa suya.
Lo bueno es estar aquí para ir viendo la película Saludos!
Es decir, que cuando la tienes grande (la memoria) y dura (el procesador) las posibilidades son mucho mayores.
Las traducciones no son una ciencia exacta. Hay juegos de palabras que son intraducibles... y tienes que elegir entre perder cierto chiste, cierto doble significado, o hacer otro chiste que sea diferente al original (dependerá si la intención principal es humorística, que da igual la historia original con tal de hacer reír, o bien si hay una intención informativa donde el chiste es secundario). Pero en este caso parece claro que no es el caso, es simplemente una traducción torpe sin ninguna justificación.
La ventaja de las bbdd documentales radica más bien en la facilidad de no tener que definir un modelo previamente para insertar en una colección y la posibilidad de añadir nuevos atributos al vuelo con la misma facilidad. Esto permite almacenar y consultar datos que no tiene que ser homogéneos necesariamente y que pueden provenir de diversas fuentes.
En mi opinión su principal debilidad es también esta y la carencia de transacciones atómicas al grabar varios documentos. Por eso hay que ser muy juicioso al elegir una tecnología u otra.P
Son necesarias ambas cosas. Innovación sin marketing, pues suele resultar ser algo muy bueno que no lo conoce nadie... y marketing sin innovación es el vendemotos, el vendedor de humo, el que "coloca" cosas que no son objetivamente lo mejor pero hace parecer que sí lo son.
Si hay suerte, el innovador sin marketing puede triunfar sin haberse esforzado apenas en comunicarlo o "venderlo". Pero tampoco es extraño el caso inverso, un cuentista que triunfa a base de "labia", de persuadir, de crear una envoltura y un halo de excelencia en algo que realmente es común o incluso peor que la media, que no aporta realmente algo mejor que los demás pero que es percibido como más valioso o "mejor".
Apple presenta una buena combinación de ambas cosas, realmente innova y también se preocupa por comunicarlo y dotarlo de un aspecto atractivo (casi pareciendo mucho más de lo que realmente es)... y así ha logrado ser la compañía más valorada de la historia, al menos en valor monetario.
Ya te digo índice != autonumerico.
Y si nos pasamos las 3 reglas principales de la normalización por el orto, si te cuento el resto ... Dan ganas de llorar lo que hacen algunos hinjinieros con la etiqueta de anís del mono.
Ni SQL está muerto ni es ineficaz ni es lento. Tan bueno es que Twitter se permite tener un modelo relacional.
Bueno, al lío.
SPAAAAAAAAAAAAMMMMMMMMMMMMMMMMMMMM
voltdb.com/leadership/dr-michael-stonebraker
Trabajo con SAP, te puedo asegurar que aproximadamente el 80% de mis clientes tienen problemas con tablas que se han ido de madre, y con algunas extepciones solo trabajo con clientes del ibex35 no me quiero ni imaginar como se las gastan en empresas yankees.
Cuando tu tabla maestra de clientes ronda el medio millon de registros (que almacena unos 40 campos por cliente), la de transacciones bancarias no me atrevo ni a decir que tamaño tiene en producción pero multiplica lo anterior x50, la de proveedores mas de lo mismo, el maestro de direcciones, la de flujo documental (pedidos ofertas pagos...)
A día de hoy nuestra solucion suele pasar por capar a los usuarios, que no puedan sacarse informes de todo si no tienen roles especiales porque pueden dejar tostado el sistema (aunque de normal les pega timeout antes de sacar la mosntruosidad que intentan calcular) pero se nos demanda cada vez mas potencia de cálculo (en sap tenemos a la vuelta de la esquina un monstruo llamado Fiori que amenaza con sacar SAP a dispositivos móviles con su jodido perfil de usuario, contenido multimedia etc.) y es un problema que llevamos viendo desde hace ya añitos. Por ahora y ya lo citan en el articulo estan desarrollando Hanna que a ver que tal (aun no me he metido en el tema por lo que me abstengo de decir nada, pero también los tiros van porque SAP quiere desligarse de Oracle, que suelen ser sus bases de datos a dia de hoy, ya que Oracle ha metido la pezuña en el terreno de los ERPs y se huelen que quieren comerle el pastel) pero creeme que el tamaño que estan alcanzando las bbdd no es solo un problema de superempresas yankees, aquí también esta pegando fuerte y tanto en el sector privado como en el público (si quieres mas datos, hace nada se fue un proyecto al garete para la comunidad de Madrid por el tamaño que alcanzaron las consultas que debia hacer el sistema que se volvieron intratables, no me preguntes cuanta pasta se tiro a la basura cuando se dieron cuenta del problema pero no fue poca y te estoy hablando de una cagada hace ya unos 3 años)
Larry Ellison approves this
¿Qué le pasa?
Ni una sola mención a la clusterización que soluciona los problemas que según él son imposibles de arreglar. Ni una sola mención a las soluciones intermedias entre SQL y noSQL (como usar una caché noSQL delante de la SQL, con los resultados que la aplicación va a necesitar o guardar los datos entre una y otra según su importancia o volumen de accesos).
En cualquier caso, me río de la base de datos de Facebook. Este no se ha asomado al tinglado que tiene Google montado, ¿no? Hadoop ni le sonará. Y de MapReduce ya ni hablamos. (#15)
Sí estoy de acuerdo en algo: hoy en día usar Oracle (salvo casos MUY concretos) es una estupidez.
Eso es un problema de administración de base de datos. Si pagas cacahuetes, tendrás monos (y no lo digo por tí, lo digo por el que diseñó esa base de datos).
Toma, una ayuda: www.postgresql.org/docs/9.4/static/ddl-partitioning.html combinado con una buena caché y un buen www.postgresql.org/docs/9.4/static/sql-cluster.html Por ejemplo.
Además de que presenta otro problema añadido, que igual la tabla Z cuando se creó estaba pensada para albergar X registros y con 3 campos claves, algo que en origen era correcto, pero han pasado 7 años (nuestras plataformas van a laaargo plazo) y el bicho ha crecido una barbaridad y ahora te exigen que accedas por campos que no eran considerados clave en origen. Muchos clientes deniegan el hecho de que puedas readaptar la tabla a nuevas condiciones (imagina adaptar un monstruo de 8 millones de registros en pro.... implica hacerlo a las tantas de la mañana un finde para tener baja demanda de usuarios y cruzar los dedos y una vela a san pancracio) por lo que te encuentras en un atolladero.
En fin que es un problemón del que no siempre sales airoso, no tenemos control absoluto del sistema (somos consultoria) y el departamento de sistemas también se cubre las espaldas al auditar (lógicamente, en el fondo entiendo a los BOFH, yo también lo haría) y bloquea desarrollos que si bien son necesarios a nivel téncico presentan tantos riesgos que acaban desechados
No te voy a negar que SAP tiene cagadas, las tiene, muy gordas, empezando porque el codigo estandard esta escrito en aleman (tocate los cojones, un producto destinado a venta internacional que tiene todo montado en un idioma minoritario (si vale el aleman lo habla mucha gente pero ambos sabemos que no es el estandard en informatica)) pero también es cierto que es un ecosistema muy grande con soluciones adaptables a cuaquier negocio, que es por lo que se instala, intentar montar desde 0 algo parecido (conozco la competencia y en muchas cosas esta aun a años luz) y puedes multiplicar el tiempo de desarrollo x10.
La ultima implantacion desde 0 que hemos hecho para una empresa de retail bastante gorda española ha pasado a producción en unos 8 meses (con sus problemas y quebraderos de cabeza si, pero en 8 meses los usuarios ya lo controlan) todos sus modulos de negocio (ojo TODOS, desde el almacen hasta recursos humanos) y eso a día de hoy no conozco otro sistema que se adapte tan rapido.
code.facebook.com/posts
Una pista: el problema está en el enlace de tu empresa con el cliente.
Si te llegan cambios de requisitos que no tienen sentido técnicamente hablando y/o el cliente no entiende la complejidad (el "precio") de hacer ese cambio, ese no es tu problema. Tú eres el técnico, tenían que haberte consultado a ti antes de darle el sí quiero al cliente. Y darle el "sí quiero" implica o bien pagarte las horas extras de fin de semana a las tantas (a precio de tinta de impresora, por supuesto), o tener unas horas el sistema apagado.
Hazlo saber a tu superior o a tu comercial porque ese tipo de ventas sólo pueden llevar a un fracaso estrepitoso a medio/largo plazo.
Estándar es la palabra o "standard", pero estandard nopes.
Más que nada porque tarde o temprano saldrá una versión open source que lo superará. Y si para entonces no estás jubilado (no sé tu edad, pero es poco probable que estés ya en la recta final...), te va a tocar reciclarte de todas formas.
Es más, no es mi área y no tomes mis palabras al pie de la letra, pero me suena que ya hay software que está alcanzando a SAP en muchos aspectos e incluso superándolo.
De todas maneras y con respecto a la esperanza de futuro, a malas malas me huelo que esto se quedará como sistema legacy al igual que le pasó a Cobol, AS400... etc. Y SAP sigue avanzando y tiene cosas chulas.
El problema con el software abierto en estos temas es que, si quieres una comunidad de usuarios para mantener yo que se Gimp, Apache, Libreoffice... etc te salen los nerds de debajo de las piedras que van a dar apoyo y soporte, si quieres montar un módulo de gestión de pedidos para el sector hospitalario.... pues la comunidad ya es bastante mas limitada, no hay recursos. Hay desarrollos prometedores como OpenERP (ahora creo que se llama Odoo o algo así) o Openbravo pero lo dicho, poca comunidadd, no cubren todas las areas de negocio, apenas tienes gente especializada... Vamos no me malinterpretes soy muy fan del software abierto (yo no sabría tirar ni una linea de codigo si no es por el, es donde aprendi lo poco que se) pero hay que reconocer que aun le queda un largo trayecto y más en aplicaciones industriales.
Y bueno, de todas maneras yo hecho el euromillon todas las semanas (la loteria es el impuesto de los tontos, lo se pero dejame engañarme) a ver si dejo la mierda de la consultoría
Y si parches mil, codigo redundante, codigo muerto, ideas felices que solucionan problemas con pinzas, documentacion escasa (o directamente nula)... y ahi es donde entramos los analistas que a base de darnos ostias leemos las mierdas de SAP Alemania con lupa, paciencia y una gallina que sacrificar a mayor gloria de satan para que nos inspire y sepamos que mierda querian hacer los guiris . El caso es que al final acaba funcionando mas o menos. Pero creeme las alternativas a dia de hoy tampoco es que esten mucho mejor.
A mí, en los test de estrés no me ha dado ninguno.
El sitio con más visitas que tengo, tuvo ayer:
12.247 sesiones
5.758 usuarios
54.032 páginas vistas
Va como un tiro, en un VPS de 10$ al mes.
Uso node+express+handlebars, mongo.
En contenedores docker, usando nginx como reverse proxy y para servir los estáticos.
Antes de la versión 3, el lock de write era por database, así que lo que hice fué meter las colecciones con muchos writes y las que tenían muchos reads en bases de datos diferentes.
Otra cosa que tienes que tener en cuenta es que si un documento crece hasta ocupar todo el padding que tiene disponible, hay que moverlo y reindexar, lo cual hace lock y puede ser lento.
Si tienes documentos que pueden crecer mucho muy a menudo, debes pensar en romper el documento en dos o varias colecciones a lo base de datos relacional.
El resto de consejos son: usar bien los índices, evitar los escaeos completos, los mapreduce y demás.
En definitiva y como con MySQL, cuando se llega a cierto volumen es necesario conocer lo que ocurre por debajo.