Organización de acceso a los datos

En esta sección vamos a estudiar las cuestiones relacionadas con la obtención, almacenamiento y solicitud de datos de precios (series temporales).

Recepción de datos del servidor comercial

Antes de que los datos de precios estén disponibles en el terminal MetaTrader 5, es necesario obtener y procesarlos. Para recibir los datos hay que conectarse al terminal comercial MetaTrader 5. Los datos llegan del servidor a petición del terminal en forma de unos bloques de barras de un minuto bien empaquetados.

El mecanismo de dirigirse al servidor para obtener los datos no depende del modo de presentar la solicitud, sea por el usuario navegando por el gráfico o sea de modo de programación en el lenguaje MQL5.

Almacenamiento de datos intermedios

Los datos recibidos del servidor se despaquetan automáticamente y se guardan en el formato intermedio especial HCC. Los datos de cada símbolo se colocan en una carpeta individual directorio_de_terminal\bases\nombre_de_servidor\history\nombre_de_símbolo. Por ejemplo, los datos del símbolo EURUSD recibidos del servidor comercial MetaQuotes-Demo estarán guardados en la carpeta directorio_de_terminal\bases\MetaQuotes-Demo\history\EURUSD\.

Los datos se escriben en los archivos con la extensión .hcc, cada archivo almacena datos de barras de minutos de un año. Por ejemplo, el archivo 2009.hcc de la carpeta EURUSD contiene datos de minutos del símbolo EURUSD del año 2009. Estos archivos se usan para la preparación de datos de precios de todos los períodos y no están destinados para el acceso directo.

Obtención de datos de un período necesario desde los datos intermedios

Los archivos auxiliares en el formato HCC desempeñan el papel de la fuente de información a la hora de construir los datos de precios para los períodos de tiempo solicitados en el formato HC. Los datos en el formato HC son series temporales que están preparadas al máximo para el acceso rápido. Se crean únicamente a la petición de un gráfico o un programa mql5 en el volumen que no supera el valor del parámetro "Max bars in charts" y se guardan en los archivos con la extensión hc para su posterior uso.

Para ahorrar los recursos, los datos relacionados con un período de tiempo se cargan y se almacenan en la memoria operativa sólo si es preciso, en caso si éstos no son requeridos durante un plazo de tiempo considerable se realiza su descarga de la memoria operativa y ellos se guardan en el archivo. Para cada período de tiempo los datos se preparan independientemente de la presencia de datos ya preparados para otros períodos. Las reglas de formación y accesibilidad de datos son iguales para todos los períodos de tiempo. Es decir, a pesar de que la unidad de almacenamiento de datos en el formato HCC sea una barra de un minuto, la disponibilidad de datos en el formato HCC no significa la disponibilidad y accesibilidad de datos del período M1 con el formato HC en el mismo volumen.

La recepción de nuevos datos desde el servidor provoca la renovación automática de datos de precios utilizados en el formato HC de todos los períodos. Esto también lleva al recálculo de todos los indicadores que los usan implícitamente como datos de entrada para el cálculo.

Parámetro "Max bars in chart"

El parámetro "Max bars in charts" limita la cantidad de barras en el formato HC disponible para los gráficos, indicadores y programas mql5. Esta limitación concierne a los datos de todos los períodos de tiempo, y sirve principalmente para ahorrar recursos del ordenador.

Al establecer los valores altos del dicho parámetro, tenemos que recordar que tratándose de un historial bastante profundo de datos de precios para los períodos temporales menores, el consumo de memoria para almacenar series temporales y buffers de indicadores puede ser de centenares de megabytes, llegando al límite de memoria operativa para el terminal de cliente (2GB para las aplicaciones MS Windows de 32 bits).

Los cambios del parámetro "Max bars in charts" tendrán su efecto una vez reiniciado el terminal de cliente. De por sí el cambio de dicho parámetro no implica ni la llamada automática al servidor a por los datos adicionales, ni la formación de barras adicionales de una serie temporal. La solicitud de datos de precios adicionales y la renovación de series temporales se hacen en caso de desplazar el gráfico en la zona de datos que faltan, o bien, solicitando los datos que faltan desde un programa mql5.

El volumen de datos solicitados al servidor corresponde a la cantidad requerida de barras de dicho período, teniendo en cuenta el valor del parámetro "Max bars in charts". La limitación puesta por el parámetro no es tan rigurosa, y en algunas ocasiones el número de barras disponibles en el período temporal puede superar insignificadamente el valor del parámetro corriente.

Disponibilidad de datos

La presencia de datos en el formato HCC, o incluso en el formato HC listo para utilizarse, no siempre supone la disponibilidad absoluta de estos datos para ser mostrados en un gráfico o para utilizarlos en programas mql5.

A la hora de acceder a los datos de precios o a los valores de indicadores desde los programas mql5, hay que recordar que su disponibilidad en un momento dado o desde un momento dado no está garantizada. Esto está relacionado con lo siguiente: con el fin de ahorrar los recursos en MetaTrader 5, no se almacena una copia completa de datos requeridos para un programa mql5, sino se proporciona un acceso directo a la base de datos del terminal.

El historial de precios para todos los períodos temporales se forma de datos comunes en el formato HCC y cualquier renovación de datos desde el servidor supone la renovación de datos para todos los períodos temporales y recálculo de indicadores. A consecuencia de esto, el acceso a los datos puede estar bloqueado, incluso si éstos estaban disponibles hace un momento.

Sincronización de datos del terminal y datos del servidor #

Puesto que un programa mql5 puede dirigirse a los datos por cualquier símbolo y período de tiempo, cabe posibilidad que los datos de la serie temporal requerida todavía no están formados en el terminal o los datos de precios requeridos no están sincronizados con el servidor comercial. En este caso es muy complicado pronosticar el tiempo de espera.

Los algoritmos que usan los ciclos de latencia no es la mejor solución. La única excepción en este caso son los scripts, puesto que ellos no tienen otra elección de algoritmo debido a no disponer del procesamiento de eventos. Para los indicadores personalizados dichos algoritmos, así como otros ciclos de latencia, no se recomiendan en absoluto porque llevan a parar el cálculo de todos los indicadores y otro procesamiento de datos de precios para dicho símbolo.

Para los Asesores Expertos e indicadores personalizados es mejor usar el modelo de eventos de procesamiento. Si durante el manejo del evento OnTick() o OnCalculate() no hemos llegado a obtener todos los datos necesarios de la serie temporal requerida, hay que salir del manejador de eventos, esperando que, al invocar el manejador la próxima vez, obtengamos el acceso a los datos.

Ejemplo de un script para descargar el historial

Vamos a ver un ejemplo - un script ejecuta la solicitud de recibir el historial acerca de un instrumento especificado desde el servidor comercial. Este script sirve para inicializar el instrumento necesario en el gráfico, el período de tiempo no importa, puesto que, y como se decía antes, los datos de precios llegan del servidor en forma de unos datos de minutos empaquetados, de los cuales, luego, se construye una serie temporal predeterminada.

Vamos a organizar todas las acciones de recepción de datos a través de una función independiente CheckLoadHistory(symbol, timeframe, start_date):

La función CheckLoadHistory() está pensada como una función universal a la que se puede llamar desde un programa cualquiera (Asesor Experto, script o indicador), por tanto hace falta tres parámetros de entrada: nombre del símbolo, período y fecha de inicio a partir de la cual necesitamos el historial de precios.

Vamos a insertar en el código de la función todas las comprobaciones necesarias antes de solicitar el historial que nos falta.  Antes de toda hay que asegurarse que el nombre del símbolo y valor del período son correctos:

En el siguiente paso nos persuadimos de que el símbolo especificado esté disponible en la ventana MarketWatch, es decir, el historial para este símbolo va a estar disponible cuando se presenta la solicitud al servidor comercial. Si éste no se encuentra en dicha ventana, hay que añadirlo usando la función SymbolSelect().

Ahora hace falta recibir la fecha de inicio del historial ya disponible para el par símbolo/período especificado. Es posible que el valor del parámetro de entrada startdate, pasado a la función CheckLoadHistory(), entre en el intervalo del historial ya disponible, entonces no hace falta presentar ninguna solicitud al servidor comercial. En este momento la función SeriesInfoInteger() con el modificador SERIES_FIRSTDATE sirve para obtener la primera fecha para el símbolo/período.

Otra verificación importante es la comprobación del tipo de programa desde el cual la función es invocada. Acordemos que el envío de la solicitud para actualizar la serie temporal con el mismo período que tiene el indicador que llama esta actualización es muy indeseable. Esta indeseabilidad está condicionada con el hecho de que la actualización de datos históricos se realice en el mismo hilo en el que opera el indicador. Por eso la posibilidad de clinch es alta. Para la comprobación vamos a usar la función MQL5InfoInteger() con el modificador MQL5_PROGRAM_TYPE.

Si hemos pasado todas las comprobaciones con éxito, vamos a hacer el último intento de evitar acudir al servidor comercial. Primero averiguaremos la fecha de inicio para la que estén disponibles los datos de minuto en el formato HCC. Vamos a solicitar este valor usando la función SeriesInfoInteger() con el modificador SERIES_TERMINAL_FIRSTDATE, y volvemos a compararlo con el valor del parámetro start_date.

Si después de todas las comprobaciones el hilo de ejecución sigue estando en el cuerpo de la función CheckLoadHistory(), esto quiere decir que hay necesidad de solicitar los datos de precios que faltan al servidor comercial. Para empezar averiguaremos el valor "Max bars in chart" usando la función TerminalInfoInteger():

Lo vamos a necesitar para no solicitar los datos de más. Luego averiguaremos la primera fecha en el historial del símbolo en el servidor comercial (sin tener en cuenta el período) mediante la función ya conocida SeriesInfoInteger() con el modificador SERIES_SERVER_FIRSTDATE.

Puesto que la solicitud es una operación asincrónica, la función se invoca en el ciclo con un pequeño retraso de 5 milisegundos hasta que la variable first_server_date adquiera un valor, o la ejecución del ciclo sea interrumpida por el usuario (IsStopped(), en este caso devuelve el valor true). Vamos a indicar un valor correcto de la fecha de inicio, desde la cual empezamos a solicitar los datos de precios en el servidor comercial.

Si de pronto la fecha de inicio first_server_date del servidor resulta ser menos que la fecha de inicio first_date del símbolo en el formato HCC, en el diario de registro aparecerá el aviso correspondiente.

Ahora estamos preparados a solicitar los datos de precios que nos faltan al servidor comercial. Vamos a presentar la solicitud en forma del ciclo y empezaremos a rellenar su cuerpo:

Los tres primeros puntos se implementan por medios ya conocidos.

Nos queda el último cuarto punto, que es la misma solicitud del historial. No podemos dirigirnos al servidor directamente pero cualquier función-Copy automáticamente inicia el envío de tal solicitud del terminal al servidor comercial si el historial en el formato HCC no es suficiente. Ya que el tiempo de la primera fecha de inicio en la variable first_date es el criterio más fácil y natural para evaluar el grado de ejecución de la solicitud, lo más fácil será usar la función CopyTime().

Cuando llamamos a las funciones que se encargan de copiar cualquier dato desde las series temporales, hay que tener en cuenta que el parámetro start (número de la barra a partir de la cual se inicia el copiado de datos de precios) siempre tiene que estar dentro de los límites del historial del terminal disponible. Si disponemos sólo de 100 barras, no tiene sentido intentar copiar 300 barras empezando de la barra con el índice 500. Tal solicitud se entenderá como errónea y no será procesada, es decir, no se cargará ningún historial desde el servidor comercial.

Precisamente por eso vamos a copiar 100 barras de una vez, empezando de la barra con el índice bars. Esto proporciona la carga fluida del historial desde el servidor comercial. En realidad se cargará un poco más de 100 barras solicitadas, es que el servidor envía el historial con una cantidad de información ligeramente sobrepasada.

Después de la operación de copiado hay que analizar el número de elementos copiados. Si el intento ha sido fallido, el valor de la variable copied será igual a cero y el valor del contador fail_cnt será aumentado a 1. El trabajo de la función será detenido después de 100 intentos fallidos.

De esta manera, en la función no sólo está implementado el correcto procesamiento de la situación corriente en cada momento de ejecución, sino también se devuelve el código de finalización, el que podemos manejar después de invocar la función CheckLoadHistory() con el fin de obtener información adicional. Por ejemplo, de esta manera:

El código entero de la función viene en el ejemplo del script que demuestra el modo correcto de organizar el acceso a cualquier dato con el procesamiento del resultado de solicitud.

Código: