Jaka jest różnica między kursorem laravel a metodą Laravel chunk?

Mamy porównanie: chunk () vs cursor()

• cursor (): High Speed
• chunk (): stałe zużycie pamięci

10,000 rekordy :

+-------------+-----------+------------+
|             | Time(sec) | Memory(MB) |
+-------------+-----------+------------+
| get()       |      0.17 |         22 |
| chunk(100)  |      0.38 |         10 |
| chunk(1000) |      0.17 |         12 |
| cursor()    |      0.16 |         14 |
+-------------+-----------+------------+

100,000 rekordy :

+--------------+------------+------------+
|              | Time(sec)  | Memory(MB) |
+--------------+------------+------------+
| get()        |        0.8 |     132    |
| chunk(100)   |       19.9 |      10    |
| chunk(1000)  |        2.3 |      12    |
| chunk(10000) |        1.1 |      34    |
| cursor()     |        0.5 |      45    |
+--------------+------------+------------+

• TestData: tabela użytkowników domyślnej migracji Laravel
• Homestead 0.5.0
• PHP 7.0.12
• MySQL 5.7.16
• Laravel 5.3.22

Cursor()

• Tylko Pojedyncze zapytanie
• Pobierz wynik wywołania PDOStatement::fetch()
• domyślnie używane jest buforowane zapytanie i pobiera wszystkie wyniki naraz.
• zamienił tylko bieżący wiersz w wymowny model

Plusy

• Minimalizuj wymowną pamięć modelu
• łatwy do manipulowania

Cons

• ogromny wynik prowadzi do out of memory
• buforowane lub niebuforowane jest kompromisem

Chunk()

• chunk query in to queries with limit and offset
• Pobierz wynik wywołania PDOStatement::fetchAll
• przekształcił wyniki w wymowne modele

Plusy

• kontrolowany rozmiar używanej pamięci

Cons

• przekształcanie wyników w wymowne modele batchly może spowodować nadmiarowość pamięci
• zapytań i wykorzystania pamięci jest traid-off

TL; DR

Kiedyś myślałem, że cursor () wykona zapytanie za każdym razem i zachowa tylko jeden wynik wiersza w pamięci. Więc kiedy zobaczyłem tabelę porównawczą @ mohammad-asghari, naprawdę się pogubiłem. To musi być jakiś bufor Za kulisami.

Śledząc Kod Laravela jak poniżej

/**
 * Run a select statement against the database and returns a generator.
 *
 * @param  string  $query
 * @param  array  $bindings
 * @param  bool  $useReadPdo
 * @return \Generator
 */
public function cursor($query, $bindings = [], $useReadPdo = true)
{
    $statement = $this->run($query, $bindings, function ($query, $bindings) use ($useReadPdo) {
        if ($this->pretending()) {
            return [];
        }

        // First we will create a statement for the query. Then, we will set the fetch
        // mode and prepare the bindings for the query. Once that's done we will be
        // ready to execute the query against the database and return the cursor.
        $statement = $this->prepared($this->getPdoForSelect($useReadPdo)
                          ->prepare($query));

        $this->bindValues(
            $statement, $this->prepareBindings($bindings)
        );

        // Next, we'll execute the query against the database and return the statement
        // so we can return the cursor. The cursor will use a PHP generator to give
        // back one row at a time without using a bunch of memory to render them.
        $statement->execute();

        return $statement;
    });

    while ($record = $statement->fetch()) {
        yield $record;
    }
}

Zrozumiałem, że Laravel buduje tę funkcję za pomocą wrap PDOStatement:: fetch(). I przez wyszukiwanie bufor PDO fetch i MySQL, znalazłem ten dokument.

Https://www.php.net/manual/en/mysqlinfo.concepts.buffering.php

Zapytania domyślnie używają trybu buforowanego. Oznacza to, że wyniki zapytań są natychmiast przesyłane z serwera MySQL do PHP, a następnie przechowywane w pamięci procesu PHP.

Więc wykonując PDOStatement:: execute() pobieramy całe wiersze wynikowe na jedynkach i zapisane w pamięci , a nie tylko jeden rząd. Jeśli wynik jest zbyt duży, spowoduje to wyjątek out of memory.

Chociaż pokazany dokument możemy użyć $pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false);, aby pozbyć się buforowanego zapytania. Ale wadą powinna być ostrożność.

Niezbuforowane zapytania MySQL wykonują zapytanie, a następnie zwracają zasób, podczas gdy dane wciąż czekają na serwerze MySQL na pobranie. To zużywa mniej pamięci po stronie PHP, ale może zwiększyć obciążenie serwera. Chyba że pełny zestaw wyników był pobierane z serwera żadne dalsze zapytania nie mogą być wysyłane przez to samo połączenie. Zapytania niebuforowane mogą być również określane jako "użyj wyniku".

chunk opiera się na paginacji, utrzymuje numer strony i wykonuje pętlę za Ciebie.

Na przykład, DB::table('users')->select('*')->chunk(100, function($e) {}) wykona wiele zapytań, aż zestaw wyników będzie mniejszy niż rozmiar kawałka(100):

select * from `users` limit 100 offset 0;
select * from `users` limit 100 offset 100;
select * from `users` limit 100 offset 200;
select * from `users` limit 100 offset 300;
select * from `users` limit 100 offset 400;
...

cursor jest oparty na PDOStatement::fetch i generatorze.

$cursor = DB::table('users')->select('*')->cursor()
foreach ($cursor as $e) { }

Zrobi jedno zapytanie:

select * from `users`

Ale sterownik nie pobiera wyniku ustawionego na raz.

Metoda cursor używa leniwych kolekcji, ale uruchamia zapytanie tylko raz.

Https://laravel.com/docs/6.x/collections#lazy-collections

Jednak metoda cursor konstruktora zapytań zwraca instancję LazyCollection. Pozwala to nadal uruchamiać tylko jedno zapytanie z bazą danych, ale także przechowywać tylko jeden wymowny model załadowany w pamięci na raz.

Chunk uruchamia zapytanie wiele razy i ładuje każdy wynik fragmentu do wymownych modeli w jeden raz.

Zrobiłem jakiś benchmark używając kursora i gdzie

foreach (\App\Models\Category::where('type','child')->get() as $res){

}

foreach (\App\Models\Category::where('type', 'child')->cursor() as $flight) {
    //
}

return view('welcome');

Oto wynik: