Wypowiedzi
-
Sugeruję :
1) albo skonsultować wszelkie kwestie licencyjne z prawnikiem kompetentnym w zakresie prawa własności intelektualnej oraz licencji o otwartym kodzie źródłowym (to drugie jest ważne, wielu prawników nie ma w tym zakresie obycia)
2) albo, wobec niejasności utworzonych przez Oracle wokół licencjonowania MySQL, przesiąść się na któryś z odgałęzionych projektów Open Source (na przykład MariaDB): http://en.wikipedia.org/wiki/MySQL#Forks
-
Marek H.:
Wcześniej już pisałem:
NIE DYSKUTUJMY O TYM CO WIDZIMY DZIŚ LUB WCZORAJ bo zarządca może nie skończył swojej roboty...
OK, zgadzam się.
Choć i tutaj znajdzie się dość zabawny kontrprzykład - ścieżki rowerowe w Nowej Soli:
http://www.drogipolskie.republika.pl/podstrony/foto_po...
Robota dość niedawna (nie da się zwalić na "zamierzchłe czasy") i wygląda na skończoną (tu chyba już nic nie można poprawić - chyba że nie znam jakiejś magicznej sztuczki której uczą na waszych uczelniach...).
Ogólnie natomiast chciałbym wyrazić opinię, że strony w rodzaju drogipolskie.republika.pl są moim zdaniem bardzo wartościowe i pożyteczne - przydałoby się ich więcej.
Tak, wzbudzają kontrowersje, mogą drażnić, ale o to właśnie chodzi - dzięki nim tematem zainteresuje się zwykły zjadacz chleba, który nad suchymi technicznymi dokumentami (przykład: http://siskom.waw.pl/obwodnica-sr-zachod.htm) przeznaczonymi dla inżynierów drogowców po prostu zaśnie.
A tacy zjadacze chleba później trafiają do samorządów i występują w roli inwestora - muszą choć trochę znać temat żeby nie dać się wpuścić w maliny łasemu na kasę wykonawcy.
Strona drogipolskie Pana Bolesława Pisańskiego jest wprawdzie wypełniona prowokacyjnymi komentarzami na temat "zostawiających w domu rozum inżynierów", ale też jest pisana z dowcipem i potrafi wciągnać w temat ludzi z plebsu.
A potrzebna jest popularyzacja tego tematu, bo obecnie większość zwykłych użytkowników dróg ma postawę pasywno-obojętną - trochę ponarzekają, a potem umilkną. Tylko umęczone podwozie wymagać będzie częstszych remontów...
Myślę, że właśnie takie strony są lekarstwem na zakorzeniony w Polsce układ w stylu iście starożytno-egipskim, z wykształconymi kapłanami drogownictwa pilnie strzeżącymi swych sekretów, i ciemnym ludem (który obejmuje nie tylko zwykły plebs - użytkowników dróg, ale i samorządy, i gałąź ustawodawczą).
Rozwiązanie problemów w polskim drogownictwie wymaga większego zaangażowania w nie ogółu społeczeństwa, powstania kultury otwartości i dzielenia się wiedzą.
To jedyny sposób na firmy, które budując i remontując naszą infrastrukturę mają 2 podstawowe cele: chcą zmaksymalizować swój przychów i zminimalizować koszty. To jedyny sposób na samorządowców, którzy zawsze obiecują przed wyborami gruszki na wierzbie i równe nawierzchnie na drogach, a po wyborach tylko pilnują swojego stołka - bo wiedzą, że większość wyborców przeszła w tryb pasywny i już zapomniała, na kogo głosowała.
My jako społeczeństwo musimy być przynajmniej na tyle kompetentni i zainteresowani tematem, aby móc skontrolować wyniki ich pracy - i jednych i drugich.
Nasi inżynierowie drogowcy będą narzekać, że "chcieliby robić rzetelnie i trwale, lecz im nie pozwalają", a nasze drogi dopóty będą w tyle Europy, dopóki odpowiednia ilość ludzi w społeczeństwie nie będzie umiała odróżnić drogi dobrze zrobionej od spartaczonej jeszcze zanim zaczną się pojawiać na niej dziury.
I dopóki nie wdroży tej umiejętności w życie, dopóki nie zacznie pamiętać i przypominać sobie faktów, kiedy obowiązek obywatelski wzywa do urn.
-
Marek H.:
Przejścia dla pieszych w naszym kraju (chodzi o ich wygląd) to też wymysł ustawodawcy - a nie Zarządcy Dróg.... Oszczędniej nie oznacza bezpieczniej!!!! proszę zwrócić na uwagę na kulturę jazdy w niemczech i w polsce??? jak kierowcy w polsce będą bardziej karani za wykroczenia to kultura się zwiększy i może będzie wtedy taniej zastosować przejścia takie jak w Niemczech ale narazie muszą być bardziej widoczne... prawo trzeba dostosowywać do warunków krajowych a nie patrzeć tylko żeby zaoszczędzić na bezpieczeństwie???
Wygląda zatem na to, że źródła problemu należy szukać w:
1) Naszej narodowej kulturze jazdy
2) Nieudolnym ustawodawstwie (ach, ci politycy...)
3) Niezorientowanych w temacie/niekompetentnych inwestorach, którzy nie potrafią właściwie ocenić wyników pracy, za którą płacą.
Mam rację?
Co do przejść dla pieszych, już rozumiem. Jednak jeśli tak u nas troszczy się o bezpieczeństwo, to co Pan powie na takie przypadki z Zielonej Góry?
http://www.drogipolskie.republika.pl/podstrony/foto_po...
-
Więcej przykładów oszczędniejszych rozwiązań zaa Odry:
Przejścia dla pieszych: http://www.drogipolskie.republika.pl/podstrony/foto_ni...
Chodniki w małych miejscowościach tylko z jednej strony ulicy: http://www.drogipolskie.republika.pl/podstrony/foto_ni...
-
Marek H.:
Pan Aleksander to informatyk... uważa że drogowcy w Polsce nic nie umieją i chciał nam pokazac podstawową wiedzę :) dziękujemy Panie Aleksandrze...
OK, przyznaję, że nie jestem w tym temacie kompetentny. Po prostu byłem w Berlinie i trochę sobie pooglądałem, a jeżdżąc przez naszą stolicę zastanawiam się, dlaczego w XI wieku na ulicach w ścisłym centrum (Emilli Plater, Stawki) jedzie się jak po pobojowisku.
Że nie ma wystarczających środków?
A co powiecie na takią opinię z tej strony (http://www.drogipolskie.republika.pl/podstrony/foto_ni...:
"To może na początek coś co świadczy że albo jesteśmy lepsi w budowaniu dróg od niemców albo jesteśmy wyjątkowymi tępakami. Zdjęcia z Frankfurtu nad Odrą i miasta Eisenhitenstad na trasie z Frankfurtu do Guben. Otóż zielona strzałka w formie tabliczki którą my dawno zastąpiliśmy kolejnym sygnalizatorem. Albo niemcy są zacofani i sknery albo my tacy bogaci i mądrzy. Raczej my jesteśmy bogaci w dziurawych skarpetach i ze słomą z buciorów wystającą bo niemcy są praktyczniejsi i jak widać do tego oszczędni."
Faktycznie, w Polsce wszędzie widzę pełno tych strzałek warunkowego skrętu w formie sygnalizatora. Nigdzie nie widziałem zwykłej taniej blaszanej tabliczki.
Widzę tu kilka wytłumaczeń:
1) Niemcy te sygnalizatory stawiali w dawnych biednych czasach (NRD - wspomniane miasta Frankfurt/Oder i Eisenhuttenstadt są na jego byłym terenie) a sygnalizacji od tego czasu nie zmieniali - bo jak się sprawdza, to po co?
2) Niemcy są zacofani w stosunku do nas (raczej tak nie jest :))
3) Niemcy są praktyczniejsi i oszczędniejsi
-
Drogowcom polecam ten link:
http://www.drogipolskie.republika.pl
"Na tej stronie znajdziecie informacje, których nie usłyszycie na żadnych studiach i uczelniach wraz z przykładami z wykonanych inwestycji tak abyście porównali teorie z praktyką. Wówczas zobaczycie jaka przepaść dzieli praktykę od teorii ale co najważniejsze jak marna jest nasza wiedza (polskich naukowców i inżynierów) na temat drogownictwa."
-
Michał Z.:
Wracając do tematu - rozwiązań jest sporo - wybór zależy od stosunku wielkości projektu do budżetu. MySQL nie potrafi obsłużyć równoległych insertów. Finał jest taki, że przy odpowiednim obciążeniu locki to poważny problem i trzeba umieć rozrzucić dane na kilka serwerów, a potem umieć je zebrać do kupy.
Interesujące rozwiązanie algorytmiczne problemu rozproszonego przypisywania unikalnych numerów:
http://www.openrowley.com/2007/02/15/numeric-serial-nu...
Zastosowane w Fedora Directory Server. Możnaby zastosować do ulepszenia trybu multimaster MySQL-a...
-
Marcin Chyłek:
Z tymi 2 zdaniami się nie zgodzę osobiście pracuje na bazie gdzie dane siegają tera właśnie przy wykorzystaniu PG. Co do multi master widzę że miałeś na myśli Slony wieć powiem tylko tyle że są alternatywy dla tego oprogramowania które się srawdzają.
PgCluster nie rozwijany od 2005 roku? Czy pojawiło się coś nowego? Chyba muszę odświeżyć swoje rozeznanie...
-
Joanna Gajdecka:
Witam,
Jesli chodzi o duża zalete SP :
- przechowuje kod juz sparwdzony, serwer każde lużne zapytanie musi sprawdzac od nowa czy jest zgodne z wymaganiami jezyka
- po każdym wykonaniu procedury zapisany jest dla niej juz execution plan, wiec o ile sie paramerty nie zmianiają nie trzeba jej od nowa kompilowac
Jednym słowem oszczedzamy serwer, mówie o MSSQL ;)
Tylko w większości przypadków, ale nie we wszystkich! Zauważ, że zasada działania, którą opisałaś, jest obosiecznym mieczem.
Zapisany uprzednio plan wykonania zapytania będzie stosowany do wszystkich przyszłych zapytań, a przecież w przyszłości rozłożenie danych w tabelach może się zmienić i ten stworzony kiedyś plan (być może przy prawie pustych tabelach), oparty na nieaktualnych już statystykach, stanie się nieoptymalny. Być może nawet skrajnie niewydajny.
W tym momencie staje się potrzebne ponowne przekompilowanie procedury. Używasz MSSQL, więc stosujesz sp_recompile albo zdajesz się na automatykę (wersja 2005), która może się odpalić w najmniej oczekiwanym momencie (logika jej działania nie jest udokumentowana). Przy czym nie ma gwarancji, że dla konkretnych danych (szczególnie warunków WHERE) uprzednio przygotowany plan będzie bliski optimum.
Dlatego bez zastanowienia można stosować procedury przechowywane tylko dla zapytań, dla których plan wykonania nie ma zastosowania (n.p. INSERT-y). W pozostałych przypadkach należy wykonać uprzednio porównawcze testy wydajności
-
Moim zdaniem powinieneś zrobić to w konfiguracji klastrowej multi master (co eliminuje wariant z PostgreSQL...).
Szkoda słyszałem że Postgres przy większych rozwiązaniach jest wydajniejszy i ma większe możliwośći optymalizacji od MySQL.
Niestety nie mogę tu zaoferować twardych danych. Robiłem na Postgresie i na MySQL-u różne systemy, ale nie miałem okazji robić należytej analizy porównawczej (jedna aplikacja, ściśle zdefiniowane obciążenie, powtarzalne testy z użyciem backend-ów PgSQL oraz MySQL - tak to należałoby zrobić aby mieć faktyczne rozeznanie).
Mnie samemu bardziej podoba się PostgreSQL ze względu na przemyślaną architekturę. Faktycznie może być sprawniejszy przy barzdiej złożonych dziedzinach problemowych. Na przykład wyposażony jest w genetyczny optymalizator zapytań, odpalający się automatycznie przy złączaniu powyżej 13 tabel - wykonuje swoją pracę znacznie szybciej, niż klasyczny optymalizator, któremu złożoność obliczeniowa rośnie geometrycznie wraz ze wzrostem ilości złączeń.
PostgreSQL ma też bogaty wybór dedykowanych typów indeksów dla potrzeb rozwiązań GIS, OLAP, oraz przetwarzania danych geometrycznych.
MySQL natomiast wygląda jak zlepek poprawek dodawanych na zasadzie późniejszej refleksji, na przestrzeni ostatnich kilku lat, bez jakiegogkolwiek uprzedniego planu rozwojowego.
Jednak czasami rozwiązania bardziej eleganckie nie sprawdzają się wcale lepiej od tych bałaganiarskich.
Za MySQL przemawia jego wykorzystanie w praktyce przez:
* Livejournal (2 mln. aktywnych użytkowników)
* Wikipedia (przedstawiać chyba nie trzeba)
* Google AdWords
* YouTube
* Digg
* Facebook
* Yahoo! Finance
* Craigslist
Tak więc masz sporo literatury na temat skalowania rozwiązań na nim opartych.
Wadą tego rozwiązania jest trudniejsze zarządzanie, brak wsparcia komercyjnego - ze wszystkimi ew. problemami zostajesz sam.
Początki są zawsze trudne. Dzięki za poświęcony czas.
Jak ktoś słusznie zauważył, na MySQL możesz wykupić komercyjne wsparcie. W przypadku PostgreSQL masz multum małych firm świadczących wsparcie (n.p. dla Europy, łącznie z Polską: http://www.postgresql.org/support/professional_support..., ale w takim przypadku zawsze trudno wybrać kogoś, kto ci da to, czego potrzebujesz.
MySQL daje ci możliwość kupienia wsparcia u samego producenta.
Do tego wykupienie MySQL przez Sun wróży kontunuację wsparcia komercyjnego na przyzwoitym poziomie.
====================
A teraz odpowiedzi dla innych kolegów:
Michał Zaborowski wrote:
Acha jest multi-master dla Postgresa - nazywa się PgCluster.
Jestem tego świadom, ale pominąłem go celowo bo:
* Tworzył go samotnie jeden japończyk, do tego kiepsko znający jęz. angielski, a od czasu jak go testowałem nie wyszło żadne nowe wydanie (tj od roku 2005)
* Replikacja jest oparta na poleceniach, nie na logu transakcji (command/statement-based replication), co stwarzać może problemy. W MySQL masz do wyboru Statement Based Replication, Row Based Replication oraz tryb mieszany Mixed Based Replication.
Piotr Likus wrote:
Jeśli nie jesteś pewien, to zrób rozwiązanie z wymienialną
warstwą danych - wtedy będzie można zmienić w razie czego.
Jesteś jednak świadom, że przy wymienialnej warstwie danych często trzeba rezygnować ze stosowania specyficznych dla danego silnika bazy danych "sztuczek", pozwalających z niego wysupłać dużo dodatkowej wydajności?
N.p. nie skorzystasz z wyszukiwania pełnotekstowego tsearch2 PostgreSQL-a bez użycia kodu SQL specyficznego dla Postgres.
Można co prawda stworzyć warstwę pośrednią na funkcjach/przechowywanych procedurach/widokach, z pewnym umownym "API", ale to ma swój narzut i w zasadzie mnoży pracochłonność przez dwa.
Wiesz, że prekompilowana funkcja zastępująca SELECT-a może wykonać się wolniej od tego SELECT-a bezpośredniego, bo na etapie kompilacji nie są optymalizatorowi zapytań znane statystyki na tabelach z przyszłego momentu wywołania funkcji i może ybrać suboptymalny plan wykonania zapytania (n.p. nierozsądną kolejność złączeń)?
Procedury i funkcje nie zawsze oferują zysk na wydajności.
-
Niestety nie dostaniesz tutaj gotowego rozwiązania na tacy, bo mało kto robi w takiej skali na bazach opensource. Moim zdaniem powinieneś zrobić to w konfiguracji klastrowej multi master (co eliminuje wariant z PostgreSQL...).
Będziesz musiał zainwestować dużo czasu w techniczne rozpracowanie tematu, ale jeśli chcesz pomocy w obraniu kierunku, to ja bym zasugerował się doświadczeniami Google-a:
http://www.mysql.com/customers/customer.php?id=75
Google wykorzystuje MySQL dla potrzeb AdWords.
Dla własnych potrzeb wzbogacili kod MySQL o bardziej skalowalną obsługę replikacji (korzystając z możliwości stwarzanych przez otwartość jego kodu źródłowego), ponieważ wymagają bezwarunkowej dostępności 24x7 przy milionach użytkowników.
Swoje łaty na kod MySQL oraz własne narzędzia usprawniające zarządzanie swym gigantycznym klastrem opublikowali otwarcie w kwietniu 2007 po pewnym czasie wykorzystywania wewnętrznie:
http://code.google.com/p/google-mysql-tools/w/list
Nie jestem na bieżąco, więc nie wiem, czy łaty te trafiły już do oficjalnego stabilnego wydania MySQL. Jeśli nie, będziesz musiał je zaaplikować ręcznie na kod MySQL-a.
No i oczywiście budowa środowiska (konfiguracja, opracowanie procedur, infrastruktura) jest sprawą nietrywialną.
Natomiast jako pocieszenie powiem tobie, że w takim przypadku nie będziesz musiał specjalnie inwestować w sprzęt klasy korporacyjnej - n.p. dla Oracle RAC musiałbyś zainwestować we współdzieloną pamięć masową, a najprostsza macierz Fibre Channel plus kontrolery HBA, plus (być może) switch FC swoje kosztują.
Tutaj miałbyś możliwość zbudować klaster ze zwykłych elementarnych, wymienialnych PC-tów, tak, jak to robi Google.
Wadą tego rozwiązania jest trudniejsze zarządzanie, brak wsparcia komercyjnego - ze wszystkimi ew. problemami zostajesz sam.
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Teoria Bezpieczeństwa
- 1
- 2
- Następna »
