Foro de elhacker.net

hola
ojalá me puedan ayudar con mi problemita

Lo que pasa es que estoy haciendo un programa que lee unos datos en un archivo de texto y funciona todo perfecto al probarlo con un documento de 4000 lineas del txt (como 700kb) (el cual entero tiene más de 4 millones de lineas y pesa 500mb aprox).

El problema es que cada vez que realizo una busqueda el programa lee todo el txt y da una respuesta y no puedo estar cargando el archivo de 500mb cada vez que quiero buscar 1 numero.

necesito que el documento de texto quede guardado en el buffer o algo y poder realizar busquedas en ese mismo txt varias veces hasta que lo desee cambiar o terminé la "session".

no se si entendí... pero lo guardas en una variable de session y fin del asunto  :o

Ps, creo que no hay otra alternativa, leerá siempre el texto o si tu le especificas una linea para leer solo cuya linea, de lo contrario primero leerá todo y luego hará la búsqueda. Es como un buscador, primero almacena todo y luego devuelve los resultados que coinciden.

Podes usar fgets y leer linea por linea hasta encontrar lo que necesitas extraer de dicho archivo. Pero si este 'scritp' tuyo lo vas a usar en un servidor web.. :P

Yo mejor te diria que busques la forma de pasar tu monstruoso .txt a una BB.DD  :)

Saludos

si no quieres depender de un servidor para la BBDD usa sqlite que es mas rápido inclusive... u ordena el archivo y usa algún algoritmo de búsqueda como la binaria (solo funciona con un número estático de datos y ordenados, es la mas rápida)

Cuando dices cargar el texto a memoria y esas cosas se me viene a la mente que quieres hacer una especie de caché y cargar una sola ves el texto para no tener que andarlo abriendo a cada rato.
En ese caso puedes almacenar el .txt en un .php donde cada linea es $linea[] = ''; después si quieres buscar algo le haces un foreach y esperar hasta el 2012 para que te resuelva lo que necesitas o inicie el script.

Por defecto en un servidor no puedes cargar todo un archivo de golpe a memoria o a una variable debido a que php tiene una configuración con el limite de memoria permitido para ejecutarse y generalmente no supera los 2mb asi que cuando quieres cargar tu super archivo el loop que vas a hacer con la busqueda te lo va a mandar al carajo.

Lo que tu necesitas es una base de datos como toda la gente que hace trabajos normales, las bases de datos en access y txt son para datos pequeños, mysql, sqlite son para trabajos normales como los que tu quieres.

Pasalo todo a una base de datos, ya que la base de datos posee su propio Buffer cache para manipular data y indices(dependiendo el motor de almacenamiento) el cual puedes manipular su tamanio. Ademas de otras ventajas que haran menos forzosas tantas entradas y salidas del disco de un archivo TXT.

Si tu archivo TXT tiene por ejemplo datos de este estilo:

marian, rodriguez
pedro, gomez
mario, perez
juana, mejia
coco, channel
pepe, lopez

Y tu quieres transportar todo a MySQL por ejemplo, sencillamente creas una tabla para acaparar la informacion anterior, que son nombres y apellidos:

CREATE TABLE ejemplo ( nombres CHAR(15), apellidos CHAR(15))

Y luego a importar :D

 
mysql> SELECT * FROM ejemplo;
Empty SET (0.00 sec)
 
mysql> LOAD DATA LOCAL INFILE '/home/marian/archivo.txt' INTO TABLE ejemplo FIELDS TERMINATED BY ',';
Query OK, 6 ROWS affected (0.00 sec)
Records: 6  Deleted: 0  Skipped: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo;
+---------+-----------+
| nombres | apellidos |
+---------+-----------+
| marian  |  sanchez  |
| pedro   |  gomez    |
| mario   |  perez    |
| juana   |  mejia    |
| coco    |  channel  |
| pepe    |  lopez    |
+---------+-----------+
6 ROWS IN SET (0.00 sec)
 
 

Donde FIELDS TERMINATED BY indica donde vas a especificar que se corte la data para pasar la subsiguiente al proximo campo  ;)

Ademas con una DB y datos pasados, podras crear indices , relacionarlos, etc, etc...

Y si tiene un usuario o cliente que se llame
María De las mercedes ozas Riquelme
xDDDD son 20 carácteres, por eso siempre ese tipo de campos para evitar errores y dar mas flexibilidad las declaro de tipo text.

Que crimen... un tipo TEXT para un nombre...  :rolleyes:  pobre optimizador del motor.

Bueno fijate, puede ocurrir eso que especificas, pero si previamente uno conoce la longitud de algo (nombres, apellidos, telefono, etc) datos alfanumericos, con esto previamente uno puede decidir que tipo de datos utilizar, CHAR solo ocupa 1 byte en memoria por caracter, VARCHAR ocupa 2 bytes por caracter ademas de que este ultimo desfragmenta mucho, TEXT por el otro lado me parece haber leido que es un tipo de dato constante como CHAR (No lo afirmo pero me parece que vi que era asi, lo confirmo manana) Y si esto realmente es asi... eso quiere decir que ya que TEXT soporta 65,400 mas o menos de bytes (cantidad de caracteres maximo en total) y recuerda que TEXT no se le puede indicar hasta que longitud almacenar ya que por defecto el almacena hasta su maxima cantidad (En este caso 65,400 mas o menos) esto quiere decir, que si tu insertas 1 nombre de 20 caracteres.. el te ocupara los bytes restantes (65,380) de ceros (Justo como hace CHAR) que son datos constantes, y si esto realmente es asi, asumo no tendras problemas en que tu datafile crezca masivamente con inserciones simples  :xD (Espero que tengas mucha capacidad de disco duro para este impacto)

Por mas largo que sea un nombre, no superaria los 50 o 60 bytes (nombre no apellido). Me fio de CHAR por ser constante, por no desfragmentarse, y para datas alfanumericas menores que 255 va de lujo. Pero TEXT es un crimen usar TEXT para esos tipos de registros.

no es la primera vez que lo mencionas xD pero me pregunto como sabes la longitud de un nombre u apellido para generalizar?

si defines char(15) por defecto se usarán los 15 bytes aunque ingrese 'a' y varchar usaría la cantidad de letras + 1 byte siempre que la columna no sobrepase los 255 caractéres, así que si usa char(50) o varchar(50) y se introduzca un nombre de 25 caracteres queda mejor parado varchar pues usaría 26 bytes en cambio char usaría los 50

Napk, desde MySQL 5.0.3 VARCHAR viene soportando un maximo de 65,400 mas o menos caracteres. Mis ejemplos son relativos, coloco CHAR(15) porque son eso ejemplos de tablas con registros chiquitos  ;)  Ahora tengo una condicion personal, si es algo que yo asumo sobrepasara de 50 bytes (Una direccion por ejemplo) pues me voy con VARCHAR porque su tamanio es variable no fijo ni constante, pero si yo se que el estandar de un primer nombre no ocupa mas de 15 o 20 caracteres, pues para nombre lo ideal seria CHAR(20).

Porque CHAR y no VARCHAR... porque me gusta cuidar la integridad de mis datos  ;)   que aunque aca influya tambien el motor de almacenamiento, si no me veo en la necesidad de dar uso de un motor transaccional por las funcionalidades que tiene y el consumo que exhige, tengo entonces yo que intentar cuidar la integridad de mis datos. Y si un tipo de dato puede ayudarme a cuidar mis registros chiquitos, le saco el provecho que requiero.

VARCHAR...simula VARCHAR como un sistema de archivos Ext2 o FAT32  :xD  donde la data se va insertando en distintos bloques sin orden alguno y dejando aveces algun bloquecito en medio vacio  :rolleyes:  todo desfragmentado ahi, ocupara menos espacio de HD en un datafile, pero prefiero que me ocupe mas bytes de disco una data constante organizada en un motor no transaccional para data chiquita, que tener que cuidar espacio del disco en un motor no transaccional con una data desfragmentadora.

Cuestion de gustos de cada quien asumo  ;)

hace tiempo no se si se acuerdan hize un sistema que se llamaba "elf ripper md5" que era un sistema web que tu entrabas y le dabas una url de una web, entonces el sistema entraba ahi y separaba el contenido palabra por palabra e ingresaba su equivalente en hash md5 al sistema para poder crear un crackeador eficiente y todos los campos eran de tipo text.

En localhost lo probé dandole varios diccionarios de texto como archivo url pero cuando lo subí a un servidor web pude almacenar mas de 5 millones de hashses y las busquedas no demoraban mas de medio segundo aunque de todas formas si es por ahorrar recursos lo óptimo sería restringir el valor de un char a por lo menos 20 si es nombre y así dependiendo el tipo de dato a almacenar y verificar la longitud de carácteres desde php antes de ser procesado en la base de datos o si no retornará un path disclosure.

Exacto WHK aunque no conoci tu sistema, si comprobaste que funcionaba asi perfecto  ;) pero para evitar eso que dices del disclosure en PHP (Y para evitarte restrinccion de envio de data entre el cliente - servidor de MySQL por dar uso de TEXT con la variable max_allowed_packet, y que luego se te trunque la data porque esta variable asi lo especifica) Mayor control con CHAR o VARCHAR

Como dije cuestion de gustos personales, todos tenemos uno.