<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comentarios en: Benchmark MySQL vs PostgreSQL vs SQLite vs MSAccess (vs ruby)</title>
	<atom:link href="http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/feed/" rel="self" type="application/rss+xml" />
	<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/</link>
	<description></description>
	<lastBuildDate>Fri, 19 Aug 2011 17:01:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Por: Daniel G.</title>
		<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/comment-page-1/#comment-106729</link>
		<dc:creator>Daniel G.</dc:creator>
		<pubDate>Tue, 22 Mar 2011 23:06:18 +0000</pubDate>
		<guid isPermaLink="false">http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/#comment-106729</guid>
		<description>Escribo por si alguien pasa por aca para que no quede tan confundido.

Se compararon peras con manzanas

Mysql tiene varios motores y ¿cual viene por defecto en linux para esta version?.

Innodb, MyIsam, etc. El segundo es extremadamente rapido para hacer select y sólo eso.
InnoDb aguanta Pk Fk y otras cosas de bases relacionales pero es mas lento.

Ni se te ocurra usar mysql sin indices.

¿Y que tal anda la configuracion por defecto que viene en linux para postgre y mysql ?

Si usas los key buffer en mysql con más memoria de la que tiene la instalación por defecto el rendimiento mejora mucho.

Si se afina la configuración de memoria para postgre su rendimiento tambien mejora mucho.

Si alguien tiene la idea de usar access (no es base de datos) tenga en cuenta que hasta algunas versiones atras tenia limite de tamaño y este no es superior a 1,7 gigas(me refiero al tamaño del archivo).
Access es muy util para vincular distintos origenes de datos y explotarlos con excel, esto es de gran ayuda para los no expertos pero no para generar un modelo de datos ni menos usarlo como base.

Los Benchmark indican claramente que Mysql es muy veloz pero en consultas simples (Select) y a Postgre lo dejan muy bien parado cuando lo sobrecargan y aumentan el hardware.

Postgre =&gt; Escalable, buen rendimiento si se sabe configurar.

MySql=&gt; Mientras más datos tiene más baja su rendimiento. Con pocos datos y en consultas de selección nadie le gana en entornos multiusuarios.Si se sabe configurar su rendimiento puede mejorar para subconsultas, join y esas cosas, sin indices es deficiente.

El asunto es saber elegir y luego configurar.</description>
		<content:encoded><![CDATA[<p>Escribo por si alguien pasa por aca para que no quede tan confundido.</p>
<p>Se compararon peras con manzanas</p>
<p>Mysql tiene varios motores y ¿cual viene por defecto en linux para esta version?.</p>
<p>Innodb, MyIsam, etc. El segundo es extremadamente rapido para hacer select y sólo eso.<br />
InnoDb aguanta Pk Fk y otras cosas de bases relacionales pero es mas lento.</p>
<p>Ni se te ocurra usar mysql sin indices.</p>
<p>¿Y que tal anda la configuracion por defecto que viene en linux para postgre y mysql ?</p>
<p>Si usas los key buffer en mysql con más memoria de la que tiene la instalación por defecto el rendimiento mejora mucho.</p>
<p>Si se afina la configuración de memoria para postgre su rendimiento tambien mejora mucho.</p>
<p>Si alguien tiene la idea de usar access (no es base de datos) tenga en cuenta que hasta algunas versiones atras tenia limite de tamaño y este no es superior a 1,7 gigas(me refiero al tamaño del archivo).<br />
Access es muy util para vincular distintos origenes de datos y explotarlos con excel, esto es de gran ayuda para los no expertos pero no para generar un modelo de datos ni menos usarlo como base.</p>
<p>Los Benchmark indican claramente que Mysql es muy veloz pero en consultas simples (Select) y a Postgre lo dejan muy bien parado cuando lo sobrecargan y aumentan el hardware.</p>
<p>Postgre =&gt; Escalable, buen rendimiento si se sabe configurar.</p>
<p>MySql=&gt; Mientras más datos tiene más baja su rendimiento. Con pocos datos y en consultas de selección nadie le gana en entornos multiusuarios.Si se sabe configurar su rendimiento puede mejorar para subconsultas, join y esas cosas, sin indices es deficiente.</p>
<p>El asunto es saber elegir y luego configurar.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: blaxter</title>
		<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/comment-page-1/#comment-43358</link>
		<dc:creator>blaxter</dc:creator>
		<pubDate>Tue, 13 May 2008 06:38:29 +0000</pubDate>
		<guid isPermaLink="false">http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/#comment-43358</guid>
		<description>&lt;strong&gt;@Marian&lt;/strong&gt;, al principio también pensé eso, pero según la documentación de MySQL (copy-paste):
&lt;blockquote&gt;
&lt;em&gt; key&lt;/em&gt;

The key column indicates the key (index) that MySQL &lt;strong&gt;actually&lt;/strong&gt; decided to &lt;strong&gt;use&lt;/strong&gt;. If MySQL decides to use one of the possible_keys indexes to look up rows, that index is listed as the key value.

It &lt;strong&gt;is&lt;/strong&gt; possible that key will name an index that is &lt;strong&gt;not&lt;/strong&gt; present in the &lt;em&gt;possible_keys&lt;/em&gt; value. This can happen if none of the &lt;em&gt;possible_keys&lt;/em&gt; indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index
&lt;/blockquote&gt;</description>
		<content:encoded><![CDATA[<p><strong>@Marian</strong>, al principio también pensé eso, pero según la documentación de MySQL (copy-paste):</p>
<blockquote><p>
<em> key</em></p>
<p>The key column indicates the key (index) that MySQL <strong>actually</strong> decided to <strong>use</strong>. If MySQL decides to use one of the possible_keys indexes to look up rows, that index is listed as the key value.</p>
<p>It <strong>is</strong> possible that key will name an index that is <strong>not</strong> present in the <em>possible_keys</em> value. This can happen if none of the <em>possible_keys</em> indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index
</p></blockquote>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Marian</title>
		<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/comment-page-1/#comment-43357</link>
		<dc:creator>Marian</dc:creator>
		<pubDate>Tue, 13 May 2008 00:20:28 +0000</pubDate>
		<guid isPermaLink="false">http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/#comment-43357</guid>
		<description>(Básicamente dice que si, que va a usar clave primaria para ambas partes y punto. ¡Qué sabiduría!. )  
Sobre el parrafo arriba mencionado, se esta mal interpretando lo que manda mysql claramente esta diciendo que no va usar la llave primaria, ni indices
en (possible_keys: NULL ) y esto es debido por el acomodo que se le esta dando a la consulta.   Cuando va ser uso de llaves o indices  aparece de la siguiente forma:  possible_keys:
PRIMARY,Fecha_Asignada
PRIMARY,Numero_Operador
PRIMARY</description>
		<content:encoded><![CDATA[<p>(Básicamente dice que si, que va a usar clave primaria para ambas partes y punto. ¡Qué sabiduría!. )<br />
Sobre el parrafo arriba mencionado, se esta mal interpretando lo que manda mysql claramente esta diciendo que no va usar la llave primaria, ni indices<br />
en (possible_keys: NULL ) y esto es debido por el acomodo que se le esta dando a la consulta.   Cuando va ser uso de llaves o indices  aparece de la siguiente forma:  possible_keys:<br />
PRIMARY,Fecha_Asignada<br />
PRIMARY,Numero_Operador<br />
PRIMARY</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: blaxter</title>
		<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/comment-page-1/#comment-43340</link>
		<dc:creator>blaxter</dc:creator>
		<pubDate>Wed, 09 Apr 2008 15:27:07 +0000</pubDate>
		<guid isPermaLink="false">http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/#comment-43340</guid>
		<description>Hay que decir que si se crean índices (en MySQL) sobre los campos &quot;otro_id&quot;, la consulta ya se resuelve igual que en PostgreSQL (al instante vamos). 

Pero no deja de sorprender que aún teniendo ya el índice de la clave primaria compuesta, haga falta (en mysql solo, postgre lo hace bien) crear explícitamente de nuevo otra clave. Lo cual puede traducirse a la regla (en MySQL) &quot;crea una clave por cada columna de una clave primaria que no esté situada en la primera posición de ésta&quot;.</description>
		<content:encoded><![CDATA[<p>Hay que decir que si se crean índices (en MySQL) sobre los campos &#8220;otro_id&#8221;, la consulta ya se resuelve igual que en PostgreSQL (al instante vamos). </p>
<p>Pero no deja de sorprender que aún teniendo ya el índice de la clave primaria compuesta, haga falta (en mysql solo, postgre lo hace bien) crear explícitamente de nuevo otra clave. Lo cual puede traducirse a la regla (en MySQL) &#8220;crea una clave por cada columna de una clave primaria que no esté situada en la primera posición de ésta&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Lek</title>
		<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/comment-page-1/#comment-43339</link>
		<dc:creator>Lek</dc:creator>
		<pubDate>Wed, 09 Apr 2008 09:49:40 +0000</pubDate>
		<guid isPermaLink="false">http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/#comment-43339</guid>
		<description>Eh, que no es que no me lo crea, es que me sorprende. Es como si te digo que me hago un programa en C y su equivalente en Java es 700 veces más rápido........ pues sorprende :D</description>
		<content:encoded><![CDATA[<p>Eh, que no es que no me lo crea, es que me sorprende. Es como si te digo que me hago un programa en C y su equivalente en Java es 700 veces más rápido&#8230;&#8230;.. pues sorprende <img src='http://bicosyes.com/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: blaxter</title>
		<link>http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/comment-page-1/#comment-43338</link>
		<dc:creator>blaxter</dc:creator>
		<pubDate>Mon, 07 Apr 2008 19:09:23 +0000</pubDate>
		<guid isPermaLink="false">http://bicosyes.com/benchmark-mysql-vs-postgresql-vs-ruby/#comment-43338</guid>
		<description>@Lek, lo he metido básicamente porque el comportamiento de MySQL me lo ha recordado. Es tan triste que por eso he metido MS Access y sqlite que, en teoría, están varios y numerosos escalones por debajo de MySQL y Postgre.

Si no te crees los resultados (yo no lo me los creía hasta que he probado en varios ordenadores y varias instalaciones de MySQL) baja el targz y pruebalo. Si no tienes instalado ruby, simplemente pilla el dump de mysql, lo metes y ejecutas la consulta por la consola, de los 30seg no te bajará sea el pc que sea.</description>
		<content:encoded><![CDATA[<p>@Lek, lo he metido básicamente porque el comportamiento de MySQL me lo ha recordado. Es tan triste que por eso he metido MS Access y sqlite que, en teoría, están varios y numerosos escalones por debajo de MySQL y Postgre.</p>
<p>Si no te crees los resultados (yo no lo me los creía hasta que he probado en varios ordenadores y varias instalaciones de MySQL) baja el targz y pruebalo. Si no tienes instalado ruby, simplemente pilla el dump de mysql, lo metes y ejecutas la consulta por la consola, de los 30seg no te bajará sea el pc que sea.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

