Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP, Java] Budowa aplikacji z dużą ilością obliczeń
Forum PHP.pl > Forum > PHP
Riggs
Witam,
otóż chcę zbudować serwis pozwalający użytkownikom na wprowadzanie danych oraz dowolną liczbę ich modyfikacji przed upłynięciem deadline (nie mogę podać dokładnie o co chodzi, dane będą na 99% liczbowe). Dla każdej wprowadzonej przez użytkownika danej będzie generowany rekord w bazie danych. Z pobieżnych obliczeń wynika że każdy użytkownik wprowadzi między 50 a max 100 rekordów tygodniowo. Nie mogę przewidzieć liczby użytkowników ale zakładam że nie będzie to portal niszowy ale do liczby użytkowników nk na pewno mu daleko.
Wracając do rzeczy. Po upłynięciu deadline'u dla każdego użytkownika ma zostać sprawdzona poprawność liczb które podał. I tu pojawiają mi się pewne wątpliwości co do zastosowania samego PHP.
Załóżmy że mam 2000 użytkowników, każdy podał 80 rekordów do sprawdzenia. Daje to dużą liczbę zapytań do bazy danych, dodatkowo każdy wynik będzie przechowywany jako nowy rekord w innej tabeli. Takie wywołanie w pętli sprawdzenia 80*2000 (czyli SELECT z bd i jakieś if'y w php) + 2000*80 nowych rekordów - zapewne zabije skrypt PHP (time out) a w najlepszym wypadku będzie mało optymalne (w PHP nie ma wątków).
Pomyślałem więc o napisaniu mini-aplikacji desktopowej w Javie która pobrała by rekordy z bd i obliczyła je na komputerze lokalnym a następnie zaktualizowała bd. Nie jest to może najszczęśliwsze rozwiązanie ale tylko to przyszło mi na razie do głowy. Myślałem też o jakimś backendzie we flexie ale nie wiem czy podoła ograniczeniom pamięciowym flash playera.
Ma ktoś doświadczenie w tworzeniu aplikacji które wykonują dużo obliczeń? Nie chcę żeby host wykopał mi stronkę po miesiącu istnienia.
Proszę o porady.
Crozin
1. Dlaczego rekordy mają być przechowywane w innych tabelach? To sugeruje błędny projekt bazy.
2. 80 * 2000 to zaledwie 160 tys. rekordów - nie jest to zbyt duża ilość danych do przetworzenia (szczególnie, jeżeli są to dane liczbowe). Dodatkowo dane, które nie są już potrzebne przy tych obliczeniach (czyt: te, które zostały już przeliczone), możesz przenieść do innej bazy/tabeli, która będzie robiła wyłącznie za archiwum danych.
3. Nie rozumiem dlaczego miałbyś przenosić część aplikacji z serwera na lokalny komputer.
4. Jeżeli te obliczenia są naprawdę tak czaso/zasobożerne proponowałbym zejść jeszcze poziom niżej niż Java, tj. C.
Riggs
Cytat
1. Dlaczego rekordy mają być przechowywane w innych tabelach? To sugeruje błędny projekt bazy.

Ok, zgodzę się, wystarczy dodatkowa kolumna przechowująca wynik dla danego zdarzenia. Choć muszę jeszcze raz przemyśleć system statystyk, które serwis ma docelowo udostępniać.
Cytat
2. 80 * 2000 to zaledwie 160 tys. rekordów - nie jest to zbyt duża ilość danych do przetworzenia (szczególnie, jeżeli są to dane liczbowe). Dodatkowo dane, które nie są już potrzebne przy tych obliczeniach (czyt: te, które zostały już przeliczone), możesz przenieść do innej bazy/tabeli, która będzie robiła wyłącznie za archiwum danych.

Nie zbudowałem jeszcze aplikacji która przechowywała by i przetwarzała takie ilości danych więc dla mnie ta liczba jest kosmiczna. I nie wiem czy czas wykonania takiej operacji w PHP nie zabije skryptu poprzez timeout (co można np sprawdzić bubble sortem dla dużej ilości danych).
Cytat
3. Nie rozumiem dlaczego miałbyś przenosić część aplikacji z serwera na lokalny komputer.

Chodzi mi o przeniesienie obliczeń na komputer lokalny tak aby serwis na którym będzie hostowana strona nie wypowiedział mi umowy (a wiem że tak się może stać jeżeli strona będzie generowała zbyt duży ruch albo zużywała zbyt dużo zasobów).
Cytat
4. Jeżeli te obliczenia są naprawdę tak czaso/zasobożerne proponowałbym zejść jeszcze poziom niżej niż Java, tj. C.
Przy wyborze technologii to chodzi już o szybkość pisania i ewentualną przenośność aplikacji (win/linux). W sumie to nie jest kluczowa sprawa.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.