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".

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.

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)

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

 
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...

Que crimen... un tipo TEXT para un nombre...    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  (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.