Serwis "a'la allegro/oferia/merlin" od małego do dużego - technologie, sposób rozwoju itp.

(1) Załóżmy, że chcemy wykonać serwis z danymi i sposobem działania takimi jak allegro czy oferia. Serwis ma obsługiwać niedużą liczbę użytkowników (powiedzmy do 200-500 maksymalnie w ciągu 3 miesięcy od uruchomienia), mamy już wszelkie założenia, scenariusze działania etc. Serwis być utworzony w czasie wolnym w przeciągu 3-5 miesięcy (czyli szybko minimalnym nakładem kosztów), nie musi błyskać, mrugać i kręcić kolorkami, ma obsługiwać sprawnie użytkowników i ich "transakcje". Serwis na początku będzie postawiony na jakimś popularnym hostingu, niedrogim i na pewno nie dedkowanym. Założenia te podyktowane są obawą, że może jednak serwis mimo różnych analiz i trendów na rynku się nie przyjmie i nie będzie dalej rozwijany.
Tu pojawia się pierwsze pytanie - jakich technologii do tego użyć, by spełnić powyższe wymagania - czyli język, ewentualne jakieś frameworki, i oczywiście baza danych.

(2) Kolejne założenie jest optymistyczne :) Serwis zaczyna się rozrastać jeśli chodzi o liczbę użytkowników i ich "transakcji". Przyrost nie jest zbyt szybki, ale jest to powiedzmy przez dwa-trzy miesiące o 200-500 użytkowników miesięcznie więcej. Potem następuje gwałtowniejszy skok, i liczba użytkowników i ich transakcji wzrasta powiedzmy 3-krotnie w ciągu miesiąca (czyli około 6 tysięcy użytkowników miesięcznie, i adekwatnie do tego liczba "transakcji").
W tym miejscu kolejne pytania - jakich technologii użyć, by to obsłużyć i płynnie przejść z prostego serwisu na prostym hostingu z części pierwszej postu do bardziej rozwiniętego systemu postawionego na wydajniejszym hostingu (jakim? jeden czy więcej serwerów dedykowanych, czy może własne sprzęty etc..) i nie zatkać się samemu na skalowaniu (w dość krótkim czasie) z systemu z (1) do (2) oraz móc dalej rozwijać system/zmieniać hosting etc. wraz z przyrostem liczby użytkowników, więc i obciążenia?

Jeżeli brakuje danych by odpowiedzieć na powyższe pytania, to poproszę o informację - będę "rozwijał myśl" :)

_{PS. Mam nadzieję, że to odpowiedni dział na taki wątek, jeśli nie, proszę o przeniesienie do właściwej części forum (także do kosza, jeśli wątek sensu nie ma :D).}

1. Takich technologii jakie doskonale znacie. Niemniej jednak 3-5 miesięcy wydaje mi się mało realne. Pisałeś kiedykolwiek jakiś większy projekt? Bo mam wrażenie że nie bardzo...
2. Jeśli napiszecie ten system porządnie to się będzie skalował. Jeśli uważacie że będziecie robić konkurencje dla amazona to możecie zaczać myśleć o jakiejś technologii która wspiera klastrowanie i rozpraszanie aplikacji, ale generalnie wątpię żeby było to wam potrzebne.

1. Masz tu niestety ograniczenie: hostingi popularne i niededykowane mają ograniczoną liczbę języków wspieranych. był niedawno temat że np hosting współdzielony asp.net jest dużo droższy niż współdzielony linuxowy... Poza tym - hulaj dusza piekła nie ma :) tyle transakcji i userów to jest "nic" :)
2. zależy od wyborów w poprzednim pkt. Jednak nawet najwięksi zaczynali od "czegoś" (nawet taka krowa jak FB zaczynała od takiego syfu jakim PHP byw czasach w których FB się zaczynał) a potem rozwijali/zmieniali (pacz Twitter z wymianą technologii, FB z wprowadzeniem JIT PHP/języka hack czy jak mu tam). Oczywiście skalowalność do pewnego momentu możesz rozwiązywać optymalizacją kodu/bazy i "rzucaniem zasobami w problem". Gdy się zorientujesz tak planowo ze to nie ma sensu - wówczas zmieniasz technologie...

Ok, dzięki za odpowiedzi... :)
Wynika z tego, że rób w czym chcesz, i tak później będziesz zmieniał wszystko prawie całkowicie, więc nie ma to znaczenia w czym robisz teraz, i w czym robić będziesz później. :)

@fourfour chcesz to napisać szybko to Python albo Ruby. Chcesz żeby dobrze się skalowało i miało wsparcie "enterprise" to weź jakąś Javę czy .NET

@Shalom chcę to napisać szybko, i jeśli "zaskoczy", to żeby dało się szybko przejść na szybkie skalowanie... teraz python/ruby , później wszystko od początku w java / .net .. :D

PS. Jestem zaskoczony, że nikt PHP nie zaproponował... :D :D

Język ma drugorzędne znaczenie. Lepiej się zastanów nad bazą danych. Bo zmigrować bazę danych na działającym systemie jest znacznie trudniej niż przepisać aplikację (hint: jedyny sensowny wybór jeśli to ma się skalować i być "always on": Apache Cassandra).

Chesz napisać szybko i żeby "zaskoczyło". Weź Scalę z Spray.IO/Akka-http. Developuje się szybko, jest skalowalne zarówno horyzontalnie(ilość maszyn) jak i wertylkanie(jakośc maszyn). baza danych? To tylko plugin. Napisz to tak by nie było świadome bazy danych. Później łatwiej będzie podpiąć czy to zwykłego SQLa, czy jakiegoś Hadoopa.

Napisz to tak by nie było świadome bazy danych

Po pierwsze - nie da się tak. Tzn. nie da się w 100%. Będzie to wyglądało tak jak aplikacje na telefon komórkowy pisane w JavaME - tzn. wykorzystują 20% możliwości sprzętu na którym stoją. O ile jeszcze w przypadku baz SQL "jakoś tam się da" Hibernatem czy innym ORMem i pewnie nie byłoby to 20%, a 50% możliwości, ale jakoś sobie nie wyobrażam przenoszenia gotowej aplikacji napisanej pod RDBMSy na NoSQLa, albo odwrotnie. Praktycznie byłoby to przepisanie całej warstwy danych od nowa.

Po drugie, nawet jak się aplikację da bezboleśnie przełączyć, to pozostaje problem migracji danych. Na działającym systemie jest to zrobić 10x trudniej niż na pustej bazie. Naprawdę znacznie taniej jest dobrze przemyśleć wybór i zaoszczędzić sobie tego bólu głowy później.

@Krolik, da się. generalnie skupiasz się nie na "zapisz dane w bazie", a na "utrwal dane". To czy za takim wywolaniem jest baza danych, czy też plik... who cares... Później jak już przyjdzie co do czego to sobie wybierzesz bazę zanych, a przełączenie pomiędzy silnikami też będzie stosunkowo proste, bo w bazie nie będzie logiki (procedur, triggerów, całego tego badziewia). W najgorszym wypadku trzeba będzie przepisać zapytania raportowe, ale to i tak zazwyczaj przy migracji trzeba zrobić (bo wszyscy "przestrzegają" standardu).

Problem w tym, że "utrwal dane" to nie jest jedna linijka czy nawet mała funkcja. Baza danych może posługiwać się innym modelem danych niż model używany po stronie aplikacji. Musisz mieć jakąś warstwę mapującą jeden model na drugi (nie ważne czy ORM, czy napisaną ręcznie). Przy dość dużych różnicach pomiędzy modelami danych w różnych systemach baz danych (choćby dokumentowe, SQL, wide-row store itp.), ta warstwa translacji będzie nietrywialna, do tego jak znam życie, to wiele tych "szczegółów implementacyjnych" będzie prznikać z jednego modelu do drugiego - np. typy identyfikatorów. I później masz aplikację, gdzie wszystkie identyfikatory encji to liczba typu Long (może nawet i opakowana w coś), zmieniasz bazę danych i okazuje się, że trzeba zmienić na UUID, bo w systemie rozproszonym UUID jest znacznie lepszym id.

@Krolik, i właśnie po to jest to utrwalDane z dobrze zdefiniowanym interfejsem, gdzie przekazujesz dane w określonym i niezależnym do implementacji po drugiej stronie formacie, by nie było tego przenikania, by zamiana po jednej czy drugiej stronie nie miała wpływu na resztę. Transakcje? Ok da się to zrobić na poziomie implementacji poszczególnych rodzajów stora. Odpowiedź do użytkowniak może ograniczyć się do ok, error + jakieś uszczegółowienie (też w zdefiniowanym formacie) i tyle.
Na dłuższą metę dzięki takiemu podejściu możesz swobodnie zmieniać każdy fragment aplikacji.

Co do problemu long/UUID. To jest ciekawy przykład na to jak taka silna separacja pozwala na uniknięcie problemu. Zarówno jeden jak i drugi identyfikator nie mają znaczenia biznesowego. Zatem są tylko szczegółem implementacyjnym, który najprawdopodobniej nigdy nie trafi do logiki biznesowej w jakiś jawny sposób. Szczególnie, że biznes ma w zwyczaju nadawać własne identyfikatory, a wtedy można już korzystać z klucza naturalnego (nawet złożonego) i to czy po drodze gdzieś na bazie masz UUID czy long dla wlasnej wygody to nie ma znaczenia. Nigdzie go nie ujawniasz, bo zawsze dostaniesz dane z klucza naturalnego.

Zgadzam się, ale nadal nie przeczy to temu co napisałem - że ta warstwa danych może być bardzo rozbudowana i że będzie trzeba mocno zmodyfikować przy zmienianiu bazy na zupełnie inną. Zapewne mniej przy zmienianiu jednego SQLa na inny SQL a bardziej przy zmienianiu np. SQL na NoSQL albo NoSQL na inny NoSQL.

Co do przenikania identyfikatorów, to czasem da się użyć klucza naturalnego, a czasem będzie to "na siłę". Skoro jesteśmy przy serwisie aukcyjnym, to co będzie identyfikatorem naturalnym aukcji? Albo wystawionego przedmiotu? Jak sprzedaję stary stół, to on nie ma tabliczki znamionowej ani metki producenta z numerem seryjnym. Opis/nazwa raczej będzie kiepskim kluczem, zważywszy że 10 innych osób może chcieć sprzedać podobny stół, a opisy i nazwy zapewne chcesz by były łatwo zmieniane. Czyli jednak najprostsze jest wygenerować id sztucznie. Teraz jak ktoś się uprze, aby we frontendzie używać longów/integerów jako id (no bo pierwsza baza to łykała), to jestem ciekaw jak wydajnie, bez dodatkowego składowania danych, zamapujesz UUIDy na Longi w dwie strony bez utraty precyzji, skoro UUID nie zmieści się w Longu...

@Krolik, ale nadal masz separację i migracja pomiędzy silnikami może odbyć się praktycznie bez zmian w apliakcji - kodzie realizującym "core bussines".

Co do klucza naturalnego aukcji to i tak potrzebujesz jakiegoś bieznesowego identyfikatora "transakcji" chociażby w celach księgowych. I takie coś się wprowadza. Ma on naturę UUID, ale co ważniejsze niesie ze sobą pewną informację na poziomie domeny, a nie jest tylko jakimś kolejnym numerem z życi wziętym. Podobnie ma się sprawa z np. numerowaniem faktur. Jest tylko jedeno ograniczenie - muszą byś numerowane kolejno. Lecz tylko tyle wystarczy, by taki numer (nawet jako zwykły long) miał pewną wartość biznesową.

@Krolik, ale nadal masz separację i migracja pomiędzy silnikami może odbyć się praktycznie bez zmian w apliakcji - kodzie realizującym "core bussines".

No super, Ty mi mówisz, że połowy aplikacji ("core business") nie trzeba będzie przepisywać, a ja Ci mówię, że drugą połowę trzeba będzie przepisać. Nawet jeśli to nie połowa, tylko 1/4 aplikacji, bo wszędzie mamy świetna architekturę i czysty kod (jak powszechnie wiadomo, w dużych projektach czysty kod i dobra architektura wylewają się z każdego elementu systemu) to i tak nie jest to takie "hop siup dzisiaj wymienimy sobie bazę danych, tak jak się zmienia kostkę wc".

@Krolik nie przesadzaj. Nikt tu nie mówi o sytuacji kiedy ktoś nagle postanowi podmienic podsystem persystencji. Ale raczej o sytuacji kiedy aplikacja np. zacznie niewyrabiać i zostanie podjęta decyzja o migracji na jakieś inne rozwiązanie i będzie można tą migrację przeprowadzić poprzez dopisanie nowego modułu, a bez konieczności modyfikacji istniejącego kodu. Plusem tego rozwiązania jest możliwość jednoczesnej pracy nad rozwojem aplikacji, bo będzie ona niezalezna od providera warstwy persystencji. Po prostu pewnego dnia podmienisz jara com.myapp.data.sql na com.myapp.data.nosql i voila.

@Krolik, przepiszesz w takim układzie nie więcej niż 5% kodu, czyli to co rzeczywiście odpowiada za komunikację ze storagem. W typowych aplikacjach właśnie dlatego musisz przepisywać pół kodu, bo walisz bezpośrednio do DAOsów, wywołujesz NativeQuery i mieszasz ORMa z JDBC. Tu tego nie ma. Po prostu :)

Gdybym ja to robił, to użyłbym Google App Engine i Pythona. Zalety to oczywiście skalowalność oraz zerowe lub niskie koszty na samym początku, więc idealne warunki dla startupu.