Której bazy danych należy użyć do śledzenia statystyk i archiwizowania wiadomości e-mail wysyłanych za pośrednictwem PHP

Question

Pytanie ma dwie strony.

1. Obsługujemy wiele plików statycznych do publicznego pobrania. Pliki PDF, zamki, obrazy, ludzie pobierają tysiące każdego każdego dnia. Śledzimy liczniki w naszej bazie danych MySQL, a szczegóły są śledzone w MongoDB (szczegóły, takie jak miejsce pochodzenia i czas pobierania).

2. Wysyłamy dużo e-maili za pośrednictwem PHP. Nasza aplikacja wysyła co miesiąc setki tysięcy e-maili, z których wiele to newslettery, powiadomienia i zaproszenia do projektów. Te wysyłane e-maile są zapisywane w bazie danych MySQL z zewnątrz ich istotne dane w odcinkach (nigdy organ lub rzeczywista zawartość e-mail, tylko nagłówki, odbiorca, czas wysłania itp)

Czy MySQL jest ok wyborem do tego? Czy Mongo? Czy powinniśmy użyć czegoś innego? Obecnie zarówno tabela archiwów e-maili, jak i tabela statystyk pobierania szybko osiągają 2 GB.

Uwaga: Dane, które przechowujemy, są dostępne regularnie, więc nie można o tym pamiętać. Korzystamy ze statystyk pobierania, aby powiadomić autorów treści, że liczba ich pobrań osiągnęła X, i używamy archiwum wiadomości e-mail do sprawdzania statusu dostawy itp. I wyświetlania go naszym pracownikom, którzy śledzą to na bieżąco. (używamy Sendgrid do dostarczania danych)

Answer 1

Myślę, że mysql może dobrze służyć twojemu celowi. jest bardziej elastyczny w Internecie, do śledzenia logu można użyć silnika mysql ARCHIVE db. mysql ma różne silniki db dla różnych celów. Myślę, że archiwum najlepiej pasuje do twojej struktury.

w ostatnim czasie zarządzam bazą danych mysql o pojemności 60 GB. była to baza danych o dużej skali, a wydajność jest dobra.

Answer 2

Moje dwa centy:

Jest to plotka dzieje wokół, że MySQL nie skaluje się bardzo dobrze z liczbą wierszy w tabeli, a PostgreSQL zarządza dużych tabel znacznie lepiej pod względem wydajności. Zdecydowanie wolałbym używać PostgreS do aplikacji z ogromnymi tabelami. (Jednak this article mówi, że ważniejszy jest sposób definiowania i korzystania z bazy danych, niezależnie od wybranego systemu.)

Jeśli czujesz się żądny przygód i chcesz zrobić coś bardziej nowoczesnego i rozproszonego, być może zajrzyj do mola i ula, które w tym samym czasie może również rozwiązać problem przechowywania dużych plików, ale wymaga nauki nowych rzeczy.

Answer 3

Porozmawiam trochę z kawałkiem MongoDB. Zakładam, że korzystasz ze sklepu MongoDB, aby szybko uzyskać dostęp do danych, a może do danych, które możesz rozpalić i zapomnieć, ale dobrze jest mieć je przy uruchamianiu raportów. Kluczem do szybkiego utrzymywania instancji MongoDB (oprócz efektywnych, wydajnych indeksów i odpowiednich zapytań, oczywiście) jest upewnienie się, że twój zestaw danych roboczych mieści się w pamięci RAM.

Ogólny rozmiar danych jest mniejszy z punktu widzenia wydajności, może być wiele, wiele razy większy od zestawu roboczego bez problemu. Miej oko na rozmiar pamięci rezydentnej (MMS jest tam twoim przyjacielem) i bądź przygotowany na odłamki, jeśli zaczniesz wykazywać tendencję do przekraczania górnych granic twojego sprzętu.

2 GB nie jest tak duże jak na zestaw danych Mongo, ani nawet na działający zestaw danych. Widziałem rozmiary danych działające w zakresie wielu terabajtów. Na podstawie podanych informacji uważam, że wybór MongoDB jest w porządku w najbliższej przyszłości.