Portada
mis comunidades
otras secciones
#13:
Esta es el típico artículo que lo lee un analista de sistemas venido a más y para el próximo proyecto clama al cielo porque SQL está obsoleto y que hay que usar nuevo paradigma porque no se que experto dijo que tal y que cual.
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: Si a los carpinteros se les contratara igual que a los programadores [ENG]/c5#c-5
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: Si a los carpinteros se les contratara igual que a los programadores [ENG]/c5#c-5
#21:
#15 Una precision Map-Reduce se usa para procesar datos. BigTable y Spanner para almacenar datos.
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.
http://research.google.com/archive/spanner.html
http://research.google.com/archive/bigtable.html
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.
http://research.google.com/archive/spanner.html
http://research.google.com/archive/bigtable.html
#46:
Leído por encima... A mí me da la sensación de que no está hablando de la guerra NoSQL vs. relacionales como aquí en los comentarios, sino el tema de rendimiento OLTP puro cortando de raíz el problema del acceso a disco.
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: https://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!
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: https://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!
#43:
#8 Es que Stonebraker no es alarmista, pero al autor de la entrevista le va el amarillismo. Simplemente dice lo mismo que tu: que hay ciertos usos que están creciendo para los que ciertas bases de datos no fueron diseñadas en principio. Y no olvidemos que Oracle, Microsoft o IBM tienen los bolsillos lo bastante profundos como permitirse comprar a cualquier competidor que empiece a despuntar en el nuevo mercado. Ni siquiera necesitan adaptarse al cambio, les basta con esperar a ver quien se adapta mejor y empezar las pujas.
#27:
#25 Me refiero a que Jobs realmente no inventó nada, pero supo vender lo que otros hicieron como nadie. No es el caso de Stonebraker. Yo tuve que aprender IMS (base de datos jerárquica) y CODASYL (base de datos en red) en la carrera, y pasar de eso a las bases de datos relacionales y un lenguaje (SQL) para consultarlas, es un paso de gigante.
Comentarios
Esta es el típico artículo que lo lee un analista de sistemas venido a más y para el próximo proyecto clama al cielo porque SQL está obsoleto y que hay que usar nuevo paradigma porque no se que experto dijo que tal y que cual.
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: Si a los carpinteros se les contratara igual que a los programadores [ENG]/c5#c-5
#13 Creo que hablan de Big Data y hoy en día esta al alcance de cualquier empresa incluso de particulares, no solo Google o Facebook tienen problemas con las transacciones.
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.
#13 Pues no estoy de acuerdo, no solo Facebook y Google tienen un problema.
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)
#71 te puedo asegurar que aproximadamente el 80% de mis clientes tienen problemas con tablas que se han ido de madre,
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: http://www.postgresql.org/docs/9.4/static/ddl-partitioning.html combinado con una buena caché y un buen http://www.postgresql.org/docs/9.4/static/sql-cluster.html Por ejemplo.
#76 Graciñas pero me da que eso escapa a mi control, para los saperos la gestión de base de datos es un proceso semi-transparente (mas allá de intentar acceder por campos clave, cuando no hay mas remedio definir claves secundarias en el sistema, categorizar el tamaño de las tablas y andarnos con ojo en los inner/outter joins, SAP es muy restrictivo)
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
#77 el bicho ha crecido una barbaridad y ahora te exigen que accedas por campos que no eran considerados clave en origen.
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.
#71 Es que SAP es una costra enorme. Son varias cosas parcheadas unas encima de otras y funcionando más o menos. Espero que alguna vez SAP muera para siempre y podamos ser felices de nuevo.
#78 tengo opiniones encontradas al respecto, porque entonces me voy a tener que reciclar
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.
#80 No digo que SAP no sea adaptable, pero el código es infumable. Y habrás visto los parches y sabrás que no explota porque a veces tienes suerte y en general tienes un millón de empresas dando soporte a SAP Hay tantas porque son necesarias por la calidad del código.
Estándar es la palabra o "standard", pero estandard nopes.
#83 Toda la puta razon del mundo, soy un inepto escribiendo sin el corrector y entono el mea culpa.
. 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.
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
#80 Yo no confiaría mi futuro laboral a que un software concreto es difícil de mantener y por eso te contratan.
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.
#84 Juas tranqui que algun as en la manga me guardo, tengo experiencia en análisis matemático y big data (Matlab Y R) algo de plsql, java, phyton , automatas programables (hice industriales en automatizacion), Unix, Linux... (digamos q soy en mi compañia la navaja suiza de los pringaos
) Estoy en SAP porque ahora mismo es de lo que suelta mas dinero en este pais (lo se lo se, fuera la cosa cambia).
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
bases de datos que son legados
Sí, vale, legacy databases, pero cuesta leer algo escrito así.
#9 Creo que se suele traducir más bien como software "heredado"... (o sistemas heredados, sistemas que tienes heredados de desarrollos anteriores o compatibilidades históricas). Pero, en fin, ya sabemos que traduciendo hay gente muy cerril o ignorante que no sabe el uso equivalente en el idioma destino al que traduce, o si lo sabe parece que tiene miedo a que le tachen de no ser fiel al original.
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.
He leído BramStoker
Facebook tiene a Cassandra, que nada tiene que ver con Oracle, DB2 o SQL Server.
#1 Son dos frases separadas Por eso hay un punto, no una coma.
#3 ¿Mande?
#3 El lenguaje es muy rico. Hay muchas formas de escribir. Si separamos todas las frases con puntos, parece que escribimos telegramas.
#1 Yo creía que tiraba de un Access por OLEDB.
#4 Qué va hombre. Usa SQLite
#5 No tenéis ni idea. Usa dBase IV, que para bigdata el no-SQL es lo mejor
#1 Facebook usando cassandra... Eso ya esta más obsoleto... Mayormente usan SQL (Su propia version de MySQL), Hive, Hadoop y ahora prestoDB para analitica. Cassandra lo sacaron ellos, pero por lo que sé, sólo se uso en las primeras versiones del messaging y luego en Instagram.
#22 Correcto, Facebook utiliza ya prestoDB [https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920], pero vamos que Stonebraker esta intentando vender su in-memory database VoltDB.
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.
Cuando la gente lea que estoy creando el nuevo Facebook con JSON XMLizado en NoSQL se van a migrar en masa.
#6 La gente ya se pasó en masa primero a Google Wave y luego a Diaspora.
#6 Eso no es nada, mi Facebook está en un servidor hecho de grafeno y lo administran gatitos
Antes de cuestionar las BD relacionarles, sería mejor que la gente comprendiera el modelo. Hay cada uno suelto por ahí diseñando...
#42
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.
Eso dijeron de cobol...
SQL ha muerto. Viva MongoDB!
#32 Los barcos han muerto. ¡Vivan los trenes!
#32 Ni de coña. Habla con alguien que la haya utilizado en proyectos reales.
#53 que le pasa?? yo lo estoy aprendiendo ahora en mongo University.
#53 yo lo estoy utilizando en proyectos reales.
¿Qué le pasa?
#74 Me refiero con mucho volumen de trafico
#88 ¿y cuál es el problema?
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.
#89 Con todo el respeto son muy pocos requests por minuto
#91 las pruebas de estres tampoco me dieron malos resultados.
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.
Otro que predica el fin de Facebook. Y van...
Nombre a la altura de "Max Power"... Homer Seal of approval!!
http://www.themoderndaypirates.com/pirates/wp-content/uploads/2010/05/max-power.jpg
Uffffff me parece una aseveración muy aventurada, si, es cierto, el almacenamiento en memoria es el futuro, pero eso no quiere decir que las bases de datos tradicionales estén obsoletas. Aún falta mucho tiempo para que el cambio de tendencia sea global, para entonces tendremos versiones de Oracle, DB2 y SQL server adaptadas para correr en memoria. ¿van tarde? tal vez, pero no podemos olvidar que cuando eres un peso pesado no es tan importante ser el primero siempre que tu producto sea bueno aunque llegue un poco más tarde que la competencia.
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.
#8 #12 #36 La ventaja principal está en el rendimiento. Las BBDD in-memory, al poder extraer cualquier dato en décimas de segundo, ocupan mucho menos que las tradicionales, ya que eliminan todos los datos estadísticos, acumulados, operaciones intermedias y similares y permiten jubilar muchas tecnologías como las bbdd analíticas. Es un avance importante que puede aprovechar cualquier empresa sin necesidad de ser Google o FB.
Es decir, que cuando la tienes grande (la memoria) y dura (el procesador) las posibilidades son mucho mayores.
#48 ¿De que te sirve tener 64GB de base de datos en memoria si tus clientes piden datos sobre 64TB que tienes en disco? Una caché, pero eso ya lo incorportan las BBDD relacionales de toda la vida... por supuesto que si sólo tienes 32GB de datos te va a ir como un tiro, pero hablamos de algo un poco más grande.
#52 Lógicamente todo depende de las necesidades y de lo que quieras invertir, pero hay servidores con hasta 12Tb de memoria
#55 Por supuesto, caballo grande, ande o no ande ¿no? pero ya se te va de presupuesto. Porque no es sólo "tener los datos en memoria", sino controlar los costes, el respaldo, etc. Si tu te montas el sistema, el mantenimiento sube, y por ahí no hay muchas empresas que ofrezcan sistemas con tanta memoria sin más (normalmente vienen acompañadas con el resto de cosas, que en este caso no quieres y no te lo podrías ahorrar). Otra cuestión es el escalado, en el caso de los discos duros puedes añadir y sustituír volúmenes en caliente, cosa que hasta donde yo sé no puedes hacer con la memoria, y tres cuartos de lo mismo a la hora de hacerte un cluster.
#48 Tener datos en memoria es algo que en mayor o menor medida tiene implementado los principales fabricantes de bbdd relacionales.
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
El futuro el VU-File
...VU-FILE trabaja siempre con todos los registros en memoria...
http://www.teknoplof.com/2015/03/11/vu-file-una-base-de-datos-para-zx-spectrum/
Este señor sí que es un genio de la informática, y no Steve Jobs, que sólo fue un genio del marketing.
#23 a ver si cae la breva y soy 'solo' un genio del marketing yo tambien
#25 Me refiero a que Jobs realmente no inventó nada, pero supo vender lo que otros hicieron como nadie. No es el caso de Stonebraker. Yo tuve que aprender IMS (base de datos jerárquica) y CODASYL (base de datos en red) en la carrera, y pasar de eso a las bases de datos relacionales y un lenguaje (SQL) para consultarlas, es un paso de gigante.
#27 desde luego, pero en el mundo moderno ya puedes inventar la pera limonera que si no la sabes vender te la comes con patatas...
#28 Exacto, dicen los gurús de negocios que las dos claves son innovación y marketing y todo lo demás son costes.
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.
Yo creo que no hay que ser tan alarmista. Hay casos donde es mejor una bbdd orientada a objetos, como mongodb, y otras en que es mejor una bbdd relacional. Depende del dominio que se trate.
#8 mongodb es orientada a objetos? en que dimension alternativa? no querrias decir orientada a documentos?
https://www.mongodb.org/about/
#37 Tienes razón, equivoque los términos. Saludos.
#8 Es que Stonebraker no es alarmista, pero al autor de la entrevista le va el amarillismo. Simplemente dice lo mismo que tu: que hay ciertos usos que están creciendo para los que ciertas bases de datos no fueron diseñadas en principio. Y no olvidemos que Oracle, Microsoft o IBM tienen los bolsillos lo bastante profundos como permitirse comprar a cualquier competidor que empiece a despuntar en el nuevo mercado. Ni siquiera necesitan adaptarse al cambio, les basta con esperar a ver quien se adapta mejor y empezar las pujas.
La memoria está muy barata, pero hay muchísimas fórmulas ya inventadas para conseguir que una base de datos relacional escale lo suficiente como para absorber una mayor cantidad de transacciones simultáneas. Y el almacenamiento masivo de datos sigue teniéndose que hacer en disco. Así que desde el punto de vista de sistemas y comercial del 90% de las empresas sigue siendo válida y útil la aproximación tradicional.
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.
#36 El tema es que te tienes que pagar un buen administrador de BBDD. Y me temo que aquí a muchos que no lo somos nos ha tocado más de una vez y dos tirar una BD lo mejor que hemos podido y claro, no es lo mismo que te lo haga alguien que sólo se dedica a BBDD. Ahora, se lo dices a mi jefe y te mira raro.
#79 Un buen administrador de BBDD siempre, tengas el producto que tengas si quieres aprovechar al máximo tus recursos. Tanto si usas BBDD relacionales como de cualquier otro tipo. Que haya productos que te encapsulen las bases de datos y a la hora de programar ni las huelas no te quita el problema de los backups o en caso que tengas que escalar, modificar o cambiar tu HW o tu SW.
Esto es un publirreportaje como una casa.
Cómo hace Google?
#7 Google originalmente hacia uso de MapReduce, luego migro a BigTable, en 2012 empezo a usar Spanner, ni idea de lo que usan ahora. Supongo que un poco de todo lo anterior + Haddop y cosas parecidas
#15 Una precision Map-Reduce se usa para procesar datos. BigTable y Spanner para almacenar datos.
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.
http://research.google.com/archive/spanner.html
http://research.google.com/archive/bigtable.html
#15 Yo creo que te has inventado le mitad de las palabras
#15 Por lo que conozco estan quitando toda la capa Batch y se centran en la capa Speed, eso significa que tienen que estar utilizando procesos enfocados en streaming, no Spark, pero algo parecido.
Me sorprende, y mucho, este artículo. La mención a Postgres (la base de datos SQL que mejor rendimiento da a día de hoy) se menciona así como de pasada y encima mal.
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.
Ejemplo de artículo de "mil" líneas mal resumido en un titular, del que no se habla casi nada.
Oracle es una mierda como un piano de gorda.
#10 Y las webs que relaccionan informática y "clientes" me dan asco.
#10 ¿qué argumentos tienes para decir que Oracle es una mierda? ¿es más mierda o menos que DB2 o SQL Server? ¿para tí que base de datos es mejor que Oracle?
#10 ¿Mysql también?
Pues Oracle ya utiliza ese tipo de tecnologías de las que hablan en la entrevista. Se llama Oracle RDBMS. Además hay muchos otros SGBD que funcionan de forma similar:
https://en.wikipedia.org/wiki/List_of_in-memory_databases
Leído por encima... A mí me da la sensación de que no está hablando de la guerra NoSQL vs. relacionales como aquí en los comentarios, sino el tema de rendimiento OLTP puro cortando de raíz el problema del acceso a disco.
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: https://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!
#46 Cierto, el problema que alude es mas sobre como escribir al disco o memoria.
#46 Chapó tu comentario. Todo dios hablando de modelos relacionales o no relacionales, cuando lo que está en juego es el acceso a disco, la velocidad de acceso, y la escalabilidad.
Ni SQL está muerto ni es ineficaz ni es lento. Tan bueno es que Twitter se permite tener un modelo relacional.
Recomiendo encarecidamente leer el artículo original. La traducción ésta es bastante pobre.
https://i.imgur.com/rmoMwOh.jpg
Larry Ellison approves this
Vamos que lo que viene a decir que HANA a dejado obsoleta a Oracle.
#35 Sí, será por eso que SAP te pone pegas para cualquier nueva implantación que pides con DB Oracle. O quizás el 15% que debe pagar SAP a Oracle por cada licencia de sus productos que usan la BD de Ellison...
Bueno, al lío.
SPAAAAAAAAAAAAMMMMMMMMMMMMMMMMMMMM
http://voltdb.com/leadership/dr-michael-stonebraker
En Facebook parace que saben lo que hacen:
https://code.facebook.com/posts
resumen : GPU+NVM
http://img.desmotivaciones.es/201102/ralph_10.jpg
Ahora ya no me espiaran?
el articulo no aparece lo de facebook y utiliza traducciones muy literales (google translate?)
#17 El articulo en ingles es mucho mucho mejor:
http://blogs.barrons.com/techtraderdaily/2015/03/30/michael-stonebraker-describes-oracles-obsolescence-facebooks-enormous-challenge/
#18 Hay que reconocerlo, el articulo original tiene mucho más sentido, ahí si tiene sentido(más o menos) lo que se dice, aún así creo que subestima y mucho la capacidad de Oracle, IBM y Microsoft para adaptarse, puede que su tecnología sea "anticuada", pero tienen ingenieros muy buenos y seguro que hace años que están trabajando en la solución y no me extrañaría nada que en un par de años aparezcan con versiones de sus bases de datos diseñadas para funcionar en memoria.
#18 cierto. Ahí sí habla de almacenamiento columnal y "el resto" (NoSQL). A ver si puedo darle una lectura completa en algún momento. Thx!
#18 Se debe leer este artículo en inglés. La traducción es solo de una parte del artículo. Si no se lee completo no tiene sentido.
El futuro volverán a ser los escribanos con una pluma y un tintero... hacedme caso!!!
Menéame, fuente inagotable de analistas y expertos en BigData (Sin acritud!!)
#73 Es que todo español lleva dentro al mejor seleccionador y al mejor político, y a alguien capaz de opinar de cualquier cosa (para muestra un botón, mírame a mi)