Что будет если оцифровать книгу в виде строки?

Оцифровка книги в строку: проблемы и решения

Суть проблемы

Если попытаться загрузить книгу целиком в одну строку (String) в Java, возникают серьёзные проблемы:

• Проблема памяти — огромное потребление RAM
• Проблема производительности — медленная обработка
• Проблема сетевых протоколов — ограничения на размер запроса
• Проблема хранилища — базы данных не рассчитаны на такие размеры

1. Проблема памяти

Расчет:

// Средняя книга: 80,000 слов
// Среднее слово: 5 символов
// В сумме: ~400,000 символов

// В Java каждый char занимает 2 байта (UTF-16)
String book = readEntireBook();  // ~800 KB одной строки

// Но это не всё!
// String в Java неизменяем (immutable)
// При каждой операции создается новая строка

String part1 = "первая половина книги";   // 400 KB
String part2 = "вторая половина книги";   // 400 KB
String fullBook = part1 + part2;          // 400 + 400 + 800 = 1.6 MB
// Промежуточные объекты не сразу удаляются!

Последствия:

String line = readEntireBook();  // 1 строка = 800 KB
String trimmed = line.trim();    // Создается новая строка 800 KB
String upper = trimmed.toUpperCase();  // Еще одна копия 800 KB
// Общее потребление памяти: 2.4 MB вместо 800 KB!

// Если это делать в цикле 1000 раз:
for (int i = 0; i < 1000; i++) {
    String processed = readEntireBook()
            .trim()
            .toUpperCase()
            .replace(" ", "");
    // Каждый проход: 2.4 MB * операции = потенциально ГБ памяти!
}

2. Проблема производительности GC (Garbage Collector)

// Full книга как одна строка
String hugeBook = ""; // 100 MB
for (int i = 0; i < 1000000; i++) {
    hugeBook += "еще одна строка"; // Каждый раз новый объект!
}

// Это О(n^2) алгоритм!
// 1-я итерация: копируем 0 символов
// 2-я итерация: копируем 1 символ
// 3-я итерация: копируем 2 символа
// ...
// n-я итерация: копируем n-1 символов
// Всего: 0+1+2+...+n = n(n+1)/2 операций

// GC будет работать постоянно, удаляя старые String объекты
// Результат: приложение замедляется на 90%+

Правильный способ:

StringBuilder sb = new StringBuilder();  // Мутабельный!
for (int i = 0; i < 1000000; i++) {
    sb.append("еще одна строка");
}
String result = sb.toString();  // Одна финальная строка

// Сложность: O(n)
// GC минимален

3. Проблема с HTTP запросами

// Попытка отправить большую книгу на сервер
String book = readEntireBook();  // 100 MB

// HTTP обычно ограничен
RestTemplate restTemplate = new RestTemplate();
restTemplate.postForObject(
        "http://api.example.com/upload",
        new TextData(book),  // Отправить 100 MB строкой
        ResponseEntity.class
);

// Типичные ошибки:
// 413 Payload Too Large — сервер отклонил
// 408 Request Timeout — слишком долго загружать
// OutOfMemoryError — память заканчивается во время отправки

Правильный способ — streaming:

public void uploadBook(File bookFile) throws IOException {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("http://api.example.com/upload"))
            .header("Content-Type", "application/octet-stream")
            .POST(HttpRequest.BodyPublishers.ofFile(bookFile))
            .build();
    
    HttpResponse<String> response = client.send(request, 
            HttpResponse.BodyHandlers.ofString());
}

// или с Spring
RestTemplate restTemplate = new RestTemplate();
restTemplate.execute(
        "http://api.example.com/upload",
        HttpMethod.POST,
        req -> req.getBody().write(Files.readAllBytes(bookFile)),
        res -> null
);

4. Проблема с базой данных

// Попытка хранить 100 MB строку в БД
String book = readEntireBook();  // 100 MB

// SQL
String sql = "INSERT INTO books (title, content) VALUES (?, ?)";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, "My Book");
ps.setString(2, book);  // 100 MB!
ps.executeUpdate();

// Проблемы:
// 1. PostgreSQL по умолчанию ограничивает размер текстового поля
// 2. Сетевой протокол БД может переполниться
// 3. Transaction станет огромным
// 4. Резервные копии займут слишком много места

Правильный способ — chunked загрузка:

const int CHUNK_SIZE = 64 * 1024;  // 64 KB chunks

try (FileInputStream fis = new FileInputStream(bookFile);
     InputStream is = new BufferedInputStream(fis, CHUNK_SIZE)) {
    
    byte[] chunk = new byte[CHUNK_SIZE];
    int bytesRead;
    int chunkNumber = 1;
    
    while ((bytesRead = is.read(chunk)) != -1) {
        String sql = "INSERT INTO book_chunks (book_id, chunk_num, data) "
                + "VALUES (?, ?, ?)";
        PreparedStatement ps = connection.prepareStatement(sql);
        ps.setLong(1, bookId);
        ps.setInt(2, chunkNumber);
        ps.setBytes(3, chunk, 0, bytesRead);
        ps.executeUpdate();
        
        chunkNumber++;
    }
}

5. Проблема Character Encoding

// Книга на разных языках может потребовать разные кодировки
String book = new String(Files.readAllBytes("book.txt"), 
        StandardCharsets.UTF_8);

// Проблемы:
// 1. UTF-8: 1-4 байта на символ — непредсказуемый размер
// 2. Если в памяти UTF-16 (Java): каждый символ 2 байта минимум
// 3. Emoji и спецсимволы могут занять 4 байта в UTF-16

// Книга 100 MB в UTF-8 может занять 200 MB в памяти Java!

Архитектурное решение: потоковая обработка

public class BookProcessor {
    
    // Вариант 1: Streaming через BufferedReader
    public void processBook(File bookFile) throws IOException {
        try (BufferedReader reader = new BufferedReader(
                new FileReader(bookFile),
                64 * 1024))  // 64 KB буфер
        {
            String line;
            int lineNumber = 0;
            while ((line = reader.readLine()) != null) {
                lineNumber++;
                processLine(line, lineNumber);
                // line удаляется из памяти после итерации
            }
        }
    }
    
    // Вариант 2: Streaming через Stream API
    public void processBookStream(File bookFile) throws IOException {
        try (Stream<String> lines = Files.lines(bookFile)) {
            lines
                .parallel()  // Можно параллельно!
                .map(String::trim)
                .filter(line -> !line.isEmpty())
                .forEach(this::processLine);
        }
    }
    
    // Вариант 3: Reactor для асинхронной обработки
    public Flux<String> processBookReactive(Path bookPath) {
        return Flux.fromIterable(() -> {
            try {
                return Files.lines(bookPath).iterator();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        })
        .buffer(1000)  // Обрабатываем по 1000 строк
        .flatMap(batch -> processBatch(batch));
    }
}

Правильная архитектура для больших файлов

Клиент               Сервер
  |                    |
  ├─ отправить        ─┤
  |  chunk 1           ├─ получить chunk
  |  (64 KB)           ├─ сохранить в БД или файл
  |                    ├─ удалить из памяти
  ├─ отправить        ─┤
  |  chunk 2           ├─ получить chunk
  |  (64 KB)           ├─ сохранить
  |                    ├─ удалить
  ├─ ...              ─┤
  ├─ отправить        ─┤
  |  chunk N           ├─ получить chunk
  |  (остаток)         ├─ собрать файл
  |                    ├─ обработать

Типичные размеры

Текстовый файл      Размер
─────────────────────────────
Страница текста     ~5 KB
Новелла (50 стр)    ~250 KB
Роман (300 стр)     ~1.5 MB
Документация        ~10 MB
Полная книга HTML   ~50 MB

Вывод

Если попытаться загрузить целую книгу в одну String:

1. Память — O(n^2) потребление при конкатенации
2. Производительность — GC переполняется, приложение замедляется
3. Сеть — HTTP ограничения, timeout
4. БД — размер транзакции слишком большой
5. Масштабируемость — невозможно обработать многогигабайтные файлы

Правильный подход:

• Streaming — обрабатывать по частям (chunk-ом)
• Async I/O — не блокировать поток
• StringBuilder — для конкатенации
• Chunked upload/download — разбить на части
• Reactive programming — Reactor, RxJava

Это одна из причин существования технологий вроде Apache Kafka для обработки огромных потоков данных.