Witam,
chciałbym zrobić bank własnych zdjęć z wyszukiwarką.

1. baza będzie przechowywała zdjęcia w 3 rozmiarach do max 10 MB
2. zakładam np do 100 -500 tyś zdjęć (kiedyś kiedyś)
3. wyszukiwanie na podstawie słów kluczowych terminu dodania zdjęcia
itd. wprowadzanych w formularzu przy uploadzie zdjęcia.
4. w przyszłości płatności

na jakiej bazie oprzeć to przedsięwzięcie, ile takie coś może
kosztować. Aktualnie strona stoi na home.pl

Pozdrawiam
Piotr

do góry

** Tom <p...@g...com> wrote:

> Witam, chciałbym zrobić bank własnych zdjęć z wyszukiwarką.

> 1. baza będzie przechowywała zdjęcia w 3 rozmiarach do max 10 MB

Po co od razu sobie ograniczenia zakładasz? System niech faktycznie składuje
jeden rozmiar zdjęcia (źródłowy), a udostępnia przeskalowane takie jakiego
potrzebuje aktualnie klient (inne na weba inne przez komórkę itd.). Rozmiar
składowanego zdjęcia nie ma tutaj znaczenie - obecnie lwia część kosztów
hostingu to *transfer* jaki generujesz, nie ile zajmujesz miejsca na dysku (to
jest tanie).

Ergo system ten powinien działać w ten sposób, że wrzucasz zdjęcie w oryginale
(tzn. już takie podciągnięte, ale w pełnej rozdzielczości), a potem automat te
pliki przekształca tak aby je wyświetlić w wygodny dla klienta sposób.

> 2. zakładam np do 100 -500 tyś zdjęć (kiedyś kiedyś)

500 tys zdjęć to generalnie byś musiał (zakładając, że codziennie byś robił
tyle samo od dziś) generować ich ok. 250 dziennie przez kolejne 5 lat - jesteś
pewien, że takie masz wymagania? Przemyślałeś to?

Nie ma sensu dziś projektować systemu tego typu na 5 lat do przodu. Zacznij od
czegoś mniejszego.

> 3. wyszukiwanie na podstawie słów kluczowych terminu dodania zdjęcia itd.
> wprowadzanych w formularzu przy uploadzie zdjęcia.

A dlaczego nie innych parametrów jak np. kolor, parametry aparatu, lokalizacja
geograficzna itd.? To też jest zakodowane w zdjęciach.

> 4. w przyszłości płatności

Będą na 100% czy się przymierzasz na razie?

> na jakiej bazie oprzeć to przedsięwzięcie,

Napisać własne.

> ile takie coś może
> kosztować.

W zależności od wymagań od kilku tysięcy złotych do nieokreślonej kwoty (nie
znamy wymagań).

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Tom pisze:

> na jakiej bazie oprzeć to przedsięwzięcie, ile takie coś może
> kosztować. Aktualnie strona stoi na home.pl

generalnie przy takich założeniach, to farma serwerów będzie potrzebna
już dla samych fotek potrzebne ci będą dyski:
10MB x 500 000 fotek = 500GB

+ raid pewnie, a jak ludzie zaczną równocześnie robić upload i download
to ci zajedzie każdy serwer operacjami dyskowymi (przy dużym ruchu). A i
pewnie transfer będzie też przekraczać wszystko co daje serwer
współdzielony.

Co do bazy to oczywiście jak nie Oracle to PostgreSQL - ostatnio
wrażaliśmy na tym bazę TecDoca (części samochodowe) i tabele mają tam po
150mln rekordów - trochę rzeźbienia było, ale jak sie dobrze porobiło
indeksy i klastrowanie i parę jeszcze zabiegów typu "magicznego" to
zapytania się wykonują po 1-2 ms ... jako silnik - bardzo polecam.

Aplikację oczywiście własną musisz zlecić/napisać

Wojtek

--
****** www.sklepzczesciami.pl ******
amortyzatory, sprzęgło, rozrząd, sprężyny zawieszenia, żarówki H4, H7

do góry

** crazy bejbi <t...@n...ma> wrote:

>> na jakiej bazie oprzeć to przedsięwzięcie, ile takie coś może kosztować.
>> Aktualnie strona stoi na home.pl

> generalnie przy takich założeniach, to farma serwerów będzie potrzebna już
> dla samych fotek potrzebne ci będą dyski: 10MB x 500 000 fotek = 500GB

Ilość danych czy 500GiB czy 5TiB (naucz się liczyć) nie determinuje tego czy
potrzebna jest "farma serwerów" - jeden serwer z palcem w dupie *przechowa*
500GiB danych, jeden serwer +macierz z palcem w dupie *przechowa* 5TiB danych -
jaka farma? Klaster byłby potrzebnu jeżeli byłoby tyle przetwarzania (wywołań),
że pojedynczy serwer by sobie nie poradził.

> + raid pewnie, a jak ludzie zaczną równocześnie robić upload i download to ci
> zajedzie każdy serwer operacjami dyskowymi (przy dużym ruchu). A i pewnie
> transfer będzie też przekraczać wszystko co daje serwer współdzielony.

Zależy ile tych ludzi będzie.

> Co do bazy to oczywiście jak nie Oracle to PostgreSQL

Niby czemu? Kolega pisząc "baza" miał na myśli prawodopodobnie ten zbiór zdjęć,
nie relacyjną bazę danych. W sensie trzymać taką ilość plików tego typu w
systemie bazodanowym to trzeba mieć ku temu poważne powody.

Ergo nie trzeba żadnego Oracle czy Posgresa (aczkolwiek to dobre systemy).
Dokładnie napisał "własne zdjęcia" - nie wiem jaką konkurencyjność jest w
stanie wytworzyć jedna osoba publikując sobie własne zdjęcia aby wytworzyć
zapotrzebowanie na transakcyjność, z którym *dowolny* system bazodanowy (niech
to nawet będzie flat files) nie wyrobi. Jedna osoba nie jest w stanie
wygenerować tylu transakcji wgrywając zdjęcia.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:

> Ilość danych czy 500GiB czy 5TiB (naucz się liczyć)

słusznie. tym gorzej dla hostingu na home :)

nie determinuje tego czy
> potrzebna jest "farma serwerów" - jeden serwer z palcem w dupie *przechowa*
> 500GiB danych, jeden serwer +macierz z palcem w dupie *przechowa* 5TiB danych -
> jaka farma? Klaster byłby potrzebnu jeżeli byłoby tyle przetwarzania (wywołań),
> że pojedynczy serwer by sobie nie poradził.

teoretycznie tak, ale to nie jest serwis do trzymania fotek swoich (tak
zrozumiałem). Jak zaczną ludzie te fotki pobierać (chyba po to są) i
uploadować - jak to ładnie policzyłeś 250 fotek dziennie przez 5 lat -
sądzę, że będzie konieczność skrócenia tego czasu do powiedzmy paru
miesięcy - liczba wgrywanych fotek się zwiększy. Ale wgrywa się raz,
pobiera wielokrotnie.

> Niby czemu? Kolega pisząc "baza" miał na myśli prawodopodobnie ten zbiór zdjęć,
> nie relacyjną bazę danych. W sensie trzymać taką ilość plików tego typu w
> systemie bazodanowym to trzeba mieć ku temu poważne powody.

znaczy jak ma zarządzać tymi fotkami inaczej ? jak dzielić na kategorie
i wyszukiwać ? przecież nie wrzuci wszystkiego w katalog i niech sobie
ludzie ściągają. Pewnie sie pojawi potrzeba liczenia ściągnięć, kto,
kiedy i, z tego co napisał również "za ile". I to raczej wymaga bazy -
nie fotki oczywiście w bazie, ale cała oprawa obsługi tych fotek. Jak
mam 500 tys fotek, to przynajmniej tyle wpisów w bazie będzie (a w
praktyce kilkakrotnie więcej) nawet dwukrotnie więcej wpisów niż fotek
to już milion rekordów. A gdzie kategorie fotek/logi = kolejne wpisy do
bazy ...

Podam przykład - jest strona małej organizacji samorządowej - jest tam
3-5 newsów dziennie wpisanych. Logowanie tego kto czytał, skąd, jakie
przeglądarki, jakie referery w ciągu miesiąca wygenerowało 25MB logów.
Oczywiście jest to pewne przegięcie z logowaniem wszystkiego, ale tam
będzie 500 tys fotek ... to zrobi ruch.

Wojtek


--
****** www.sklepzczesciami.pl ******
amortyzatory, sprzęgło, rozrząd, sprężyny zawieszenia, żarówki H4, H7

do góry

** crazy bejbi <t...@n...ma> wrote:

>> nie determinuje tego czy potrzebna jest "farma serwerów" - jeden serwer z
>> palcem w dupie *przechowa* 500GiB danych, jeden serwer +macierz z palcem w
>> dupie *przechowa* 5TiB danych - jaka farma? Klaster byłby potrzebnu jeżeli
>> byłoby tyle przetwarzania (wywołań), że pojedynczy serwer by sobie nie
>> poradził.

> teoretycznie tak, ale to nie jest serwis do trzymania fotek swoich (tak
> zrozumiałem).

To źle zrozumiałeś. Naucz się liczyć i czytać. Napisał wyraźnie 500 000 * 10MB
- to 5 TiB oraz "własnych zdjęć".

(...)

>> Niby czemu? Kolega pisząc "baza" miał na myśli prawodopodobnie ten zbiór
>> zdjęć, nie relacyjną bazę danych. W sensie trzymać taką ilość plików tego
>> typu w systemie bazodanowym to trzeba mieć ku temu poważne powody.

> znaczy jak ma zarządzać tymi fotkami inaczej ?

Normalnie tak jak wszyscy (np. Facebook, NK itd.) to robią - wrzucają na cloud
storage i wywołują ID/CAP fotki.

> jak dzielić na kategorie i wyszukiwać ?

To są metadane - te są w bazie. Ja zrozumiałem, że Ty potrzebujesz Oracle aby
trzymać pliki ze zdjęciami (a nie ich metadane) w bazie jako BLOB. *Czasami* to
jest zasadne np. jak masz jakąś specyficzną topologię czy wymagania odnośnie
replikacji między węzłami czy coś w tym rodzaju. W każdym razie aby to robić to
trzeba mieć do tego poważne powody bo normalnie się wrzuca pliki na storage
jako pliki.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:

> To źle zrozumiałeś. Naucz się liczyć i czytać. Napisał wyraźnie 500 000 * 10MB
> - to 5 TiB oraz "własnych zdjęć".

masz widzę zacięcie nauczycielskie :)

"bank własnych zdjęć z wyszukiwarką" może oznaczać - to moja
interpretacja, w odniesieniu do płatności - że chodzi o zrobienie czegoś
jak www.istockphoto.com. Pewnie sie rozpędziłem.

> To są metadane - te są w bazie. Ja zrozumiałem, że Ty potrzebujesz Oracle aby
> trzymać pliki ze zdjęciami (a nie ich metadane) w bazie jako BLOB. *Czasami* to

nie zakładałem trzymania fotek w bazie. w tym przypadku to niecelowe.

Ale tych metadanych jest sporo - oczywiście zależnie od tego - czy to
rozwiązanie do "swoich fotek" dla siebie, czy to baza do uploadu przez
ludzi i ew. sprzedawania fotek (tą drugą opcję zakładałem)

wojtek

--
****** www.sklepzczesciami.pl ******
amortyzatory, sprzęgło, rozrząd, sprężyny zawieszenia, żarówki H4, H7

do góry

** crazy bejbi <t...@n...ma> wrote:

>> To źle zrozumiałeś. Naucz się liczyć i czytać. Napisał wyraźnie 500 000 *
>> 10MB - to 5 TiB oraz "własnych zdjęć".

> masz widzę zacięcie nauczycielskie :)

:P

> "bank własnych zdjęć z wyszukiwarką" może oznaczać - to moja interpretacja,

"Własne zdjęcia" nie da się inaczej zinterpretować jak po prostu zdjęcia, które
sam zrobiłem. Niech siedzi sztab osób i nonstop uploaduje zdjęcia, które ja
nonstop wykonuję - niech się tak dzieje to i tak nie wygenerujesz takiej
konkurencyjności/transakcyjności jakich się nie da obsłużyć jakkolwiek (jedyne
ograniczenie to moc przetwarzania, która jest obecna w każdym współczesnym
sprzęcie klasy serwera). No po prostu nie zrobisz (fizycznie niewykonalne) i
nie obrobisz takiej ilości zdjęć. No chyba, że zdjęcia podciągniemy pod film.
;P

> w odniesieniu do płatności - że chodzi o zrobienie czegoś jak
> www.istockphoto.com. Pewnie sie rozpędziłem.

Też tak to zrozumiałem ale na zasadzie, że gościu na razie nie wie co ze sobą
zrobić to sobie zrobi portfolio zdjęć, a jak się to uda to chciałby na tym
zarabiać w ten sposób.

I OK - ale wyznaję zasadę małych kroków, lepiej w tym roku zrobić sobie proste
portfolio i poczekać jak to się rozwinie, a w następnym roku ew. zrobić sobie
na tym eCommerce.

Lepiej tak niż (jak przypuszczam) nie mając o tym zielonego pojęcia przyjąć
jakieś zajebiste wymagania na N lat do przodu, zainwestować w to kupę pieniędzy
podczas gdy nie jest się nawet pewnym co do podstawowej formy serwisu.

>> To są metadane - te są w bazie. Ja zrozumiałem, że Ty potrzebujesz Oracle
>> aby trzymać pliki ze zdjęciami (a nie ich metadane) w bazie jako BLOB.
>> *Czasami* to

> nie zakładałem trzymania fotek w bazie. w tym przypadku to niecelowe.

To źle się zrozumieliśmy. :)

> Ale tych metadanych jest sporo

E tam. Typowa fotka ma z 3MiB, a metadanych to jest *góra* kilka KiB.

> - oczywiście zależnie od tego - czy to rozwiązanie do "swoich fotek" dla
> siebie, czy to baza do uploadu przez ludzi i ew. sprzedawania fotek (tą drugą
> opcję zakładałem)

Wyraźnie napisał "własnych zdjęć".

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

uuu... ale wywiazala sie dyskusja, padło kilka slów kluczowych i muszę
je dokladnie przeanalizować gdyż jak słusznie zauważyliście moja
wiedza w tej dziedzinie nie jest dogłębna :).
Baza dotyczy dosc niszowej dziedziny i skierowana do okreslonej grupy
ludzi, którzy chca znaleźć szybko wysokiej jakości zdjęcie (przy
pomocy wyszukiwarki) niekoniecznie chodzac po katalogach (w tej
dziedzinie sa wylacznie takie katalogi).
Ile bedzie zdjec to sie okaze ale juz mam kilku chetnych do
udostepnienia rowniez swoich prac wiec rzucilem 500 k.
Nie chcę również rozważać rozwiązania nierozwojowego ale dużych
inwestycji rowniez nie chce poczyniać, opcja z prostą baza
przechowujaca slowa kluczowe czy metadane oraz linki do zdjec
upakowanych gdzies po serwerach wydaje sie rozsądna.

Jak jest z bezpieczenstwem danych, kosztami na cloud storage, jakie sa
ceny jakie serwery polecacie w przypadku takich rozwiazan?
Zależy mi przede wszystkim na dobrym mechanizmie wyszukującym i
spięciu tego do kupy.. kwestię ilości i wielkości fotek może pomińmy
ważne aby baza danych poradziła sobie z 100k + rekordów?

Jak dalej to poprowadzić jakie są wasze doświadczenia.
Chciałbym aby baza stanęła do końca roku..
Pzdr
Piotr

do góry

"Tom" napisał:

> Jak dalej to poprowadzić jakie są wasze doświadczenia.
> Chciałbym aby baza stanęła do końca roku..

Jak chcesz to zrobić poważnie to:

Zrób biznesplan.
Określ w biznesplanie maksymalne wydatki na aplikację.

Stwórz specyfikację taką, żeby nie przekroczyć
maksymalnych wydatków i żeby zawierała
podstawowe funkcjonalności.

Wykonawcę znajdź przed lub po stworzeniu specyfikacji.
Możesz też znaleźć osobną firmę do stworzenia specyfikacji
i do wykonania aplikacji.


pozdrawiam,
wr,
www.isonet.pl

do góry