Personalmente creo haber tenido mucha suerte ya que por una cosa o por otra he participado en varios proyectos que manejan grandes bases de datos, actualmente con Resultados de fútbol y BeSoccer trabajo a diario con un gran volumen de datos que me ayuda a ir cogiendo experiencia a la hora de afrontar el planteamiento de nuevas funcionalidades o mejoras para el proyecto.
A mi manera de ver lo más importante es llegar a comprender que el problema al final se reduce en conocer perfectamente la tecnología utilizada y cuáles son sus ventajas y desventajas.
Un ejemplo claro está en el uso de MySQL, seguro que alguna vez has escuchado aquello de que MySQL no es recomendado para ser utilizado con grandes tablas. Pero realmente MySQL no es lento con grandes tablas sino que para conseguir un gran rendimiento con MySQL es necesario diseñar la base de datos siendo consciente de lo que puede y no puede hacer el motor de base de datos, tampoco digo con esto que MySQL es mejor que Oracle o PostgreSQL sino que lo que funciona y es eficaz en una no tiene porque serlo en las otras.
Veamos algunas de las posibles claves a la hora de mejorar la escalabilidad de una base de datos MySQL:
1. Motor de base de datos
Acertar en la elección del motor de base de datos (MyISAM ó InnoDB)
Cómo comentamos hace unos días hay que ser conscientes de las ventajas y desventajas de cada uno de ellos.
2. Buffers
Cuando no hay memoria suficiente para el manejo de la base de datos notaremos un descenso gradual del rendimiento, la solución sería asegurarnos que tenemos memoria suficiente para el volumen de datos que estamos utilizando.
3. Índices
Es muy sencillo comprender la importancia de los índices, sin un índice, MySql tiene que iniciar una búsqueda por el primer registro y leer toda la tabla para encontrar los registros relevantes.
4. Consultas lentas
Si los anteriores puntos no nos dan la solución probablemente nos tengamos que centrar en la optimización de las consultas, una tarea complicada con la que podemos ahorrar mucho tiempo si conseguimos desde el principio detectar las consultas lentas (slow queries).
Si ninguno de estos puntos soluciona nuestro problema de escalabilidad tendremos que intentarlo con alguno de las siguientes soluciones que son algo más complicadas.
Llegado a este punto en el que necesitamos escalar nuestra base de datos y ninguna de las anteriores soluciones ya nos sirven tendremos que decidir entre:
Añadir más recursos a un nodo del sistema para mejorar el rendimiento de la base de datos, se trataría de hacer una inversión en hardware.
Pros:
Casi todos los sistemas escalan bien verticalmente.
Fácil de implementar
Fácil de administrar
Contras:
Alto coste del hardware
Agregar más nodos al sistema. Se puede escalar horizontalmente con mejoras de hardware (agregar nuevas computadoras al sistema) ó con mejoras de software (Replicación de datos ó “Sharding” por ejemplo)
Pros:
Coste lineal
Contras:
Difícil de implementar
Difícil de administrar
Se puede optar por está opción, habitualmente se escala de manera verticalmente mientras el presupuesto lo permita y cuando ya aumentan excesivamente los costos se escala horizontalmente.
Es relativamente difícil llegar a tener problemas con la base de datos y si lo llegamos a tener será una buena noticia porque significa que nuestro proyecto es lo suficientemente grande como para comenzar a buscar solución a unos problemas que de ser solucionados nos van a permitir seguir creciendo.
Escalar verticalmente es relativamente fácil ya que mientras haya dinero para soportar el coste de hardware no tendremos problemas de escalabilidad, el verdadero reto es conseguir escalar de manera horizontal manteniendo controlado el coste de desarrollo, es realmente complicado porque si llegamos a este punto seguramente careceremos de ejemplos prácticos de cómo hacerlo ya que las estructuras de bases de datos pueden ser muy dispares, por ello no hay ningún método infalible.
Las bases de datos son un componente indespensable en el desarrollo de páginas web, a menudo los desarrolladores se pueden decantar por diferentes lenguajes de programación (PHP, Python, Ruby on Rails, etc) pero al final casi todos utilizan MySql como elemento principal e indispensable para el manejo de los datos.
Personalmente pienso que es relativamente fácil escribir código funcional en pocas horas y unirlo a un buen diseño que en conjunto formen una aplicación útil, sin embargo este tipo de combinaciones tienden a no escalar bien debido a su alta dependencia a la base de datos, por ello en la gran mayoría de ocasiones nos vendría bien invertir tiempo en el análisis y optimización de la estructura de datos que estemos utilizando.
Estos son algunos de los errores más comunes que se suelen cometer en MySql.
Son los dos motores de base de datos más famosos y el uso de uno u otro es una decisión bastante importante.
MyISAM es usada por defecto pero no por ello es la mejor opción, si estamos pensando en un proyecto experimental es una buena opción, sin embargo en la mayoría de ocasiones no es la mejor solución, vamos a citar alguna de las claves por las que es más recomendado el uso de InnoDB.
1. MyISAM no soporta las claves foráneas
2. Integridad de datos
3. En MyISAM con cada escritura se bloquea la tabla entera por lo que en cada “INSERT” o “UPDATE” estaremos bloqueando la tabla, a pequeña escala no se suele notar pero a medida que la exigencia de la base de datos sea mayor la disminución de rendimiento es considerable.
Nunca debes confiar en el usuario en cuánto a la entrada de datos se refiere, para ello hay que asegurarse de filtrar y limpiar los datos en el lado del servidor y de esa manera evitar errores inesperados y posibles ataques de SQL injection.
UTF-8 nos soluciona muchos problemas en cuanto a internacionalización de aplicaciones se refiere.
Cuando eres nuevo en MySQL a menudo tratas de solucionar problemas a la hora de sacar y filtrar datos con PHP esto es un grave error ya que es bastante más lento, puede que tengas que perder tiempo en investigar pero seguro que a ese problema que tienes hay una solución con MySQL.
Un ejemplo simple sería sacar la media de un valor en una tabla de la base de datos, si no sabes de MySQL seguramente trates de obtener el total en PHP y dividas las suma por el número de filas que has sacado de la tabla, esto en MySQL se puede hacer fácilmente con el uso de la función AVG().
Recuerda que en casi todos los casos será más efectiva una buena consulta con MySQL.
Cómo hemos comentado anteriormente la gran mayoría de errores a la hora de escalar un proyecto se encuentran en la base de datos, por ello es muy importante tomar un tiempo en la optimización de consultas, la elección de los índices, el tamaño de los campos y los filtros que vas a utilizar son preguntas necesarias a la hora de enfrentarte a una consulta.
Hay un gran número de tipo de datos, a pequeña escala seguramente de igual una mala elección pero a medida que nuestra base de datos crece si el tipo de datos escogido es erróneo los problemas que vamos a tener van a ser grandes. Por eso antes de usar un DATETIME piensa si en ese caso específico sería más recomendable el uso de un DATE, o siel valor de un campo sabes que no va a sobrepasar cierta cantidad de cifras mira si te interesa utilizar un TINYINT en lugar de un INTEGER.
En muy pocos casos se tiene que recurrir al uso del * en las consultas SELECT, por varios motivos, el primer y principal motivo es que estás seguramente recogiendo más datos de los que necesitas, otro motivo es que realmente no sabes con exactitud que campos estás recuperando de la base de datos y si la consulta tiene algún JOIN la cosa se complica considerablemente.
Lo más recomendable es no recurrir nunca a este recurso salvo en casos excepcionales y tratar en todo momento exactamente los datos que necesitas.
Esta lista de errores la he sacado de una entrada en SitePoint Blogs: Top 10 MySQL Mistakes Made By PHP Developers
en: Api|Desarrollo Web
Twitter es una de las redes sociales de mayor crecimiento, como ya todos sabemos permite a los usuarios postear mensajes de una longitud reducida en número de caracteres. A través de las API de Twitter cualquiera puede crear aplicaciones que comuniquen con el servicio de la mencionada red social.
Hay un gran número de posibilidades si nos planteamos comunicar nuestro sitio web con Twitter, no me refiero a la implementación sino a las diferentes funcionalidades que podemos integrar en nuestro sitio web si decidimos comunicarlo con Twitter.
En este caso vamos a ver la opción más sencilla pero a su vez también la más utilizada, actualizar el estado de una cuenta de Twitter desde un script PHP.
Si hacemos una búsqueda en Google seguramente encontremos tutoriales que nos explican como utilizar la API de Twitter gracias al uso de la librería CURL, pero este método quedo obsoleto hace unos meses y si intentamos implementarlo recibiremos el siguiente error: “basic authentication is not supported”
< ?php
include '../../twitter.php';
$message = 'New movie ...';
$url = 'http://twitter.com/statuses/update.xml';
$curl_handle = curl_init();
curl_setopt($curl_handle, CURLOPT_URL, "$url");
curl_setopt($curl_handle, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl_handle, CURLOPT_POST, 1);
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, "status=$message");
curl_setopt($curl_handle, CURLOPT_USERPWD, "$username:$password");
$buffer = curl_exec($curl_handle);
curl_close($curl_handle);
if (empty($buffer)) {
echo "error!";
} else {
echo 'success!';
}
?>
Cómo acabamos de comentar este método ya no funciona ya que ahora es necesario el uso de Oauth
Para aquellos interesados en trabajar con la API de Twitter por primera vez y para aquellos que necesitan actualizar el código que ha quedado obsoleto en estos últimos meses debido al cambio, os recomiendo el siguiente artículo (en inglés).
Resumiendo un poco hay que realizar tres sencillos pasos:
1. Registrar una aplicación en: http://dev.twitter.com/apps/new. Tienes que dar a esta aplicación permisos de lectura y escritura para poder actualizar el estado de tu cuenta de Twitter.
2. Tienes que obtener 4 claves para conseguir actualizar el estado de la cuenta, estas son las claves necesarias: Consumer key, Consumer secret, Access Token (oauth_token), Access Token Secret (oauth_token_secret)
3. Descarga twitteroauth.
Ejemplo de uso (para actualizar el estado de una cuenta Twitter desde PHP):
< ?php $consumerKey = 'insert your consumer key'; $consumerSecret = 'insert your consumer secret'; $oAuthToken = 'insert your access token'; $oAuthSecret = 'insert your token secret'; require_once(twitteroauth.php'); $tweet = new TwitterOAuth($consumerKey, $consumerSecret, $oAuthToken, $oAuthSecret); $statusMessage = 'Prueba'; $tweet->post('statuses/update', array('status' => $statusMessage)); ?>
TweetNginx es un servidor web de alto rendimiento escrito por Igor Sysoev, desarollado para una de las web más visitadas de Rusia (Rambler), además se trata de una de las mejores alternativas a Apache, líder indiscutible del mercado. Actualmente se calcula que el 7% de páginas web corren bajo Nginx. Algunas de esas páginas son [...]
en: Desarrollo Web
A pesar de que en estos últimos años la velocidad de acceso a Internet ha aumentado el aumento de peso de las aplicaciones web ha hecho que se nivele la balanza y los desarrolladores deben de tener cuidado con el peso de sus páginas web, si a esto sumamos la gran cantidad de usuarios que se conectan desde dispositivos móviles con una velocidad ciertamente limitada tenemos que hacer un esfuerzo para conseguir que el peso de nuestras aplicaciones web no sea excesivo y los tiempos de espera se reduzcan al máximo.
En SitePoint podemos encontrar nueva causas que provocan la obesidad de una página web.
1. Over-the-top advertising
2. Inappropriate use of plugins
3. Not optimizing images
4. Not using image sprites
5. Over-reliance on JavaScript frameworks
6. Inefficient HTML
7. Embedding CSS and JavaScript
8. Not exploiting CSS cascades or shorthand notation
9. Not using compression
Seguro que con un poco de tiempo y siguiendo estos consejos podemos aligerar un poco el peso de las páginas web.
en: Desarrollo Web
Catull es la tipografia que se utilizó para la creación de uno de los logos más famosos del mundo “el logo de Google”, la tipografia Catull fue diseñada por Gustav Jaeger en el año 1982 y desde Agosto del año 1999, Google la emplea para su logo.
El problema de esta fuente es que a pesar de poder encontrarla para descargar en algunos sitios es una fuente de pago por lo que deberías comprarla si no la encuentras para descarga en alguna página.