I have a problem with viewing chunks of a very large text file. This file, approximately 19 GB, is obviously too big to view by any traditional means.

I have tried head 1 and tail 1 (head -n 1 and tail -n 1) with both commands piped together in various ways (to get at a piece in the middle) with no luck. My Linux machine running Ubuntu 9.10 cannot process this file.

How do I handle this file? My ultimate goal is to hone in on lines 45000000 and 45000100.

  • Thinking of writing a quick Python script to read the lines and print the ones I need to file, but I can imagine this taking a long time... – nicorellius Feb 21 '12 at 0:04
  • Are all the lines the same length? – Paul Feb 21 '12 at 0:10
  • @Paul - unfortunately, they are not the same length. – nicorellius Feb 21 '12 at 0:15
  • You can try split to make the large file easier to work with. – iglvzx Feb 21 '12 at 0:24
  • 1
    Ok. Any processing of a file that large will take time, so the answers below will help that. If you want to extract just the part you are looking for and can estimate approximately where it is you can use dd to get the bit you are after. For example dd if=bigfile of=extractfile bs=1M skip=10240 count=5 will extract 5MB from the file starting from the 10GB point. – Paul Feb 21 '12 at 1:38
up vote 11 down vote accepted

You should use sed.

sed -n -e 45000000,45000100p -e 45000101q bigfile > savedlines

This tells sed to print lines 45000000-45000100 inclusive, and to quit on line 45000101.

  • 1
    It's still very slow, almost like head -45000000,45000100p bigfile | tail -100 > savedlines – Dmitry Polushkin Jul 27 '15 at 8:30
  • tail+|head is faster by a good 10-15%. – erich Mar 16 at 19:26

Create a MySQL database with a single table which has a single field. Then import your file into the database. This will make it very easy to look up a certain line.

I don't think anything else could be faster (if head and tail already fail). In the end, the application that wants to find line n has to seek through the whole file until is has found n newlines. Without some sort of lookup (line-index to byte offset into file) no better performance can be achieved.

Given how easy it is to create a MySQL database and import data into it, I feel like this is a viable approach.

Here is how to do it:

DROP DATABASE IF EXISTS helperDb;
CREATE DATABASE `helperDb`;
CREATE TABLE `helperDb`.`helperTable`( `lineIndex` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `lineContent` MEDIUMTEXT , PRIMARY KEY (`lineIndex`) );
LOAD DATA INFILE '/tmp/my_large_file' INTO TABLE helperDb.helperTable (lineContent);
SELECT lineContent FROM helperTable WHERE ( lineIndex > 45000000 AND lineIndex < 45000100 );

/tmp/my_large_file would be the file you want to read.

The correct syntax to import a file with tab-delimited values on each line, is:

LOAD DATA INFILE '/tmp/my_large_file' INTO TABLE helperDb.helperTable FIELDS TERMINATED BY '\n' (lineContent);

Another major advantage of this is, if you decide later on to extract another set of lines, you don't have to wait hours for the processing again (unless you delete the database of course).

  • So this is a good solution, indeed. I got it to work with the sed command below, and identified my lines. But now I have a follow up question that the database method may be better suited for. I now need to delete a couple hundred lines from the file. – nicorellius Feb 21 '12 at 18:18
  • I'm sure sed could do that as well. Of course, if you had the data in the database it would be trivial to export a new file with just the lines you want. – Der Hochstapler Feb 21 '12 at 18:22
  • Thanks again. I took the sed answer (because it gave me more immediate pleasure ;--) but gave you an up-vote because I will use your method in the future. I appreciate it. – nicorellius Feb 21 '12 at 18:37
  • 1
    You could try adding a FIELDS TERMINATED BY '\n' to the LOAD DATA line. – Der Hochstapler Feb 21 '12 at 22:35
  • 1
    I'm sorry, there was a mistake in my code. I also added the correct syntax for your case (tested this time). – Der Hochstapler Feb 22 '12 at 0:20

Two good old tools for big files are joinand split. You can use split with --lines=<number> option that cut file to multiple files of certain size.

For example split --lines=45000000 huge_file.txt. The resulted parts would be in xa, xb, etc. Then you can head the part xb which would include the the lines you wanted. You can also 'join' files back to single big file.

  • Awesome, thank you, I totally forgot about the split command. – siliconrockstar Oct 30 '17 at 21:15

You have the right tools but are using them incorrectly. As previously answered over at U&L, tail -n +X file | head -n Y (note the +) is 10-15% faster than sed for Y lines starting at X. And conveniently, you don't have to explicitly exit the process as with sed.

tail will read and discard the first X-1 lines (there's no way around that), then read and print the following lines. head will read and print the requested number of lines, then exit. When head exits, tail receives a SIGPIPE signal and dies, so it won't have read more than a buffer size's worth (typically a few kilobytes) of lines from the input file.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.