Zmienność szybkości wstawiania SQL

Question

Skrypt, nad którym pracuję, ma na celu aktualizację tabeli bazy danych, która rejestruje kraj użytkowania i status wszystkich adresów IP (lub prawie wszystkich z nich). Obecnie utrzymuję to w prostocie i gromadzę tylko dane z 5 RIR-ów (regionalne rejestry internetowe) i zapisuję je w mojej bazie danych.

Początkowo prędkości były niepraktyczne, ale zostały poprawione w znaczący sposób poprzez zmniejszenie ilości informacji w dzienniku i grupowanie wstawek SQL w grupy o wartości 1000 i za pomocą pojedynczego zapytania. Jednak po uruchomieniu skryptu dostaję bardzo duże różnice w szybkości wstawiania SQL i zastanawiałem się, czy ktoś wie dlaczego.

Oto niektóre z prędkości, które zarejestrowałem. W teście wyodrębniłem czas potrzebny do wykonania iteracji skryptu w PHP i czasu potrzebnego do zastosowania instrukcji sql, ale nie uwzględniłem czasów PHP na poniższej liście, ponieważ efekt był znikomy; nie więcej niż 1 sekunda dla nawet największych bloków danych.

Badanie Szybkości (liczba wierszy danych są wstawiane pozostaje w całym opisie)

Test 1 Całkowita SQL czas uruchamiania: 33 sekund

Test 2 Całkowita SQL czas uruchamiania: 72 sekund

Test 3 Tota l Czas wykonywania SQL: 78 sekund

Inne testy trwały od około 30 sekund do około 80 sekund.

Mam dwa pytania:

1) Czy mogę przyjąć tych różnic jako sposobu na świecie, czy jest jakiś powód, dla nich?

2) Byłem zdenerwowany z powodu wstawienia ~ 185000 rzędowych wstawek w jedno zapytanie. Czy jest jakikolwiek powód, dla którego powinienem unikać jednego zapytania dla tych wstawek? Nie pracowałem z tą ilością danych zapisywaną jednorazowo.

Dziękuję

__

tabela bazy danych jest następująca.

Sorage Engine - InnoDB

Kolumny:

id - int, klucz podstawowy

rejestru - varchar (7)

code - varchar (2)

typ - varchar (4)

start - varchar (15)

wartość - int

data - datetime

status - varchar (10)

Answer 1

1) Should I accept these disparities as the way of the world, or is there a reason for them? 

Różnice w prędkości może być spowodowane konkurencyjnych procesów uzywajac disk-IO - więc czekam na zasoby. Jeśli jest to serwer produkcyjny, a nie samotny serwer testujący, to z pewnością niektóre inne procesy żądają dostępu do dysku.

2) I felt nervous about lumping the ~185000 row inserts into one query. Is there any reason I should avoid using one query for these inserts? I've not worked with this amount of data being saved at one time before. 

Powinieneś również podzielić wstawki na grupy wstawek X i wstawić każdą grupę jako transakcję.

Ustalenie wartości X w inny sposób poza eksperymentalnie jest trudne.

Grupowanie przekładek w transakcje zapewnia, że ​​dane są zapisywane (zatwierdzane) na dysku tylko po każdej transakcji, a nie po każdej (automatycznie zatwierdzonej) wstawce.

Ma to dobry wpływ na dysk-IO, a zgrupowanie wielu wstawek w jednej transakcji może mieć zły wpływ na dostępną pamięć. Jeśli ilość niezatwierdzonych danych jest zbyt duża dla bieżącej pamięci, system DBMS rozpocznie zapisywanie danych w dzienniku wewnętrznym (na dysku).

Więc X zależy od liczby wstawek, ilości danych powiązanych z każdą wstawką, dozwolonych parametrów pamięci/użytkownika/sesji. I wiele innych rzeczy.

---

Istnieje kilka fajnych (bezpłatnych) narzędzi od percona. Pomagają monitorować aktywność DB.

Można również spojrzeć na vmstat zegarek -n .5 „vmstat”

Zobacz ilość i zmienność danych są zapisywane na dysku przez działalność w środowisku produkcyjnym.

Uruchom skrypt i poczekaj, aż zauważysz wzrost liczby bajtów zapisywanych na dysku. Jeśli zapisanie kroku jest prawie stałą wartością (ponad normalne użycie w produkcji), to wymachuje, jeśli jest to rytmiczne, to pisze tylko dla zatwierdzenia.