MongoDB czy CouchDB - nadają się do produkcji? [Zamknięte]

Zastanawiałem się, czy ktoś może mi powiedzieć, czy MongoDB lub CouchDB są gotowe na środowisko produkcyjne .

Patrzę teraz na te rozwiązania pamięci masowej (w tej chwili faworyzuję MongoDB), ale te projekty są dość młode, więc przewiduję, że będę musiał ciężko pracować, aby przekonać mojego kierownika, że ​​powinniśmy to przyjąć Nowa technologia.

Chciałbym wiedzieć:

1. Kto używa dziś MongoDB lub CouchDB w środowisku produkcyjnym?

2. Jak korzystasz z MongoDB / CouchDB?

3. Jakie problemy (jeśli w ogóle) napotkałeś podczas przyjmowania tego nowego mechanizmu przechowywania (i jak je pokonałeś)?

4. Jak poradziłeś sobie z problemami migracyjnymi, z którymi musiałeś sobie poradzić?

5. Czy masz jakieś dobre / złe doświadczenia z którymś z tych rozwiązań, którym chcesz się podzielić?

Jestem CTO 10gen (twórcy MongoDB), więc jestem nieco stronniczy, ale zarządzam także kilkoma stronami, które używają MongoDB w produkcji.

businessinsider używa mongo w produkcji od ponad roku. Używają go do wszystkiego - od użytkowników i postów na blogu, po każdy obraz w witrynie.

shopwiki używa go do kilku rzeczy, w tym do analizy w czasie rzeczywistym i warstwy buforowania. Robią ponad 1000 zapisów na sekundę w dość dużej bazie danych.

Jeśli przejdziesz na stronę mongodb Production Deployments , zobaczysz osoby, które używają mongo w produkcji.

Jeśli masz pytania dotyczące skali lub zakresu wdrożeń produkcyjnych, opublikuj je na naszej liście użytkowników, a my z przyjemnością pomożemy.

BBC i meebo.com używać CouchDB w produkcji i tak też jeden z moich klientów. Oto lista innych osób korzystających z Couch: CouchDB na wolności

Głównym wyzwaniem jest umiejętność organizacji dokumentów i zaprzestanie myślenia o danych relacyjnych.

SourceForge używa MongoDB. Zobacz tę prezentację lub przeczytaj tutaj .

W naszych sklepach korzystamy z CouchDB jako zamiennika MySQL (70,0000 produktów / sklep, w sumie 4 miliony atrybutów wszystkich produktów, połączenia między przedmiotami).

Nasze cele to:

1. Łatwa replikacja z master-db do kilku klientów z różnymi dokumentami.

2. Szybkie wstępnie obliczone dane, takie jak „ile części mam z tym atrybutem i tym filtrem, dopasowując się do tych warunków”

fakty:

1. Nasze sklepy działają teraz znacznie szybciej niż MySQL (i baza danych mysql potrzebowała dodatkowo 1-3 dni wstępnego obliczania (więc aktualizacja była dwa razy w miesiącu), dzięki czemu dane były gotowe do zliczania i filtrowania produktów, CouchDB potrzebuje 5 godzin, więc moglibyśmy aktualizować dane produktu każdej nocy)
2. Konfigurowanie (filtrowane) dystrybucji danych i kopii zapasowych w węzłach sklepu jest szybkie i łatwe

ale również:

1. Zrozumienie mapy / redukcji i ograniczeń braku połączeń jest dość trudne
2. Brak operacji na danych takich jak „usuń gdzie” lub „zaktualizuj gdzie” bez programów zewnętrznych
3. Replikacja działa dobrze, chyba że występuje problem; wtedy naprawdę trudno jest ustalić, jaki był powód (dla początkujących)
4. Instalacja CouchDB bez plików binarnych (tak, niektóre są na wolności, ale nie dla każdego OS / wersji) może być trudne, jeśli nie jesteś maniakiem Linuksa. Społeczność CouchDB jest jednak pomocna (#couchdb) i na szczęście istnieją firmy (cloudant, iriscouch), które oferują usługi od bezpłatnego do dużego biznesu.
5. CouchDB idzie naprzód, więc dzieje się wiele zmian (ulepszeń), które mogą zmienić ich sposób pracy. Ale podstawowe rzeczy pozostają stabilne.

W rezultacie: MySQL jako baza danych do tworzenia i utrzymywania danych jest niezawodna oraz łatwa do zrozumienia i obsługi. Myślę, że tego nie zmienimy. Ale nie chcę też przegapić mocy widoków CouchDB i łatwości konfiguracji replikacji.

Kanapy produkcyjne czasami powodowały problemy po miesiącach pracy z powodu błędnej konfiguracji i zapomnianych logrotatów (tworzenie widoku trwa zbyt długo lub zawiesza się, replikacja zatrzymuje się), ale nigdy nie traciły danych i zawsze można je łatwo zresetować.

W produkcji używam CouchDB. Obecnie przechowuje wszystkie te „opcjonalne” pola, które nie były w oryginalnym schemacie DB. A teraz myślę o przeniesieniu wszystkich danych do CouchDB.

Przyznaję, że to dość ryzykowny krok. Po pierwsze, ponieważ nie jest to jeszcze wersja 1.0. A po drugie, ponieważ jest głodny przestrzeni. Według moich obliczeń plik CouchDB (z indeksami) jest ~ 30 razy większy niż baza danych MySQL z tymi samymi wierszami. Ale jestem pewien, że wszystko będzie dobrze.

CouchDB 0.11 (wydany pod koniec marca) jest wersją „freeze” dla wersji 1.0. Oznacza to, że utrzymamy kompatybilność z bieżącym API dla 1.0, więc teraz jest dobry moment, aby ponownie przyjrzeć się CouchDB, jeśli nie będziesz od dłuższego czasu.

Wersja kodu źródłowego CouchDB 0.11 jest dostępna tutaj. Są tutaj powiązane instalatory binarne i inne gadżety.

Nic nie wiem o MongoDB, ale z FAQ CouchDB :

Czy CouchDB jest gotowy do produkcji?

Tak, zobacz InTheWild, aby uzyskać częściową listę projektów korzystających z CouchDB. Innym dobrym przeglądem są studia przypadków CouchDB

Ponadto niektóre linki:

• Re: Aktualny stan CouchDB?
• SimpleDB, CouchDB i inne „NOWE” magazyny danych - informacje zwrotne

W produkcji używamy couchdb i od tego czasu projekt trafił pod parasol Apache.

Używamy go do przechowywania wszystkiego, co w innym przypadku moglibyśmy użyć dbms, oraz wszelkiego rodzaju nieuporządkowanych danych. Osobiście bardzo podoba mi się sposób, w jaki możesz wrzucać do niego wszelkiego rodzaju dane i używać widoków, aby wyrzucać to, czego nie potrzebujesz w zależności od sytuacji.

Najtrudniejsze było odejście od sposobu myślenia dbms. Napisaliśmy własne narzędzia do migracji, gdy format pamięci zmienił się tylko dla bezpieczeństwa, więc to nie był tak naprawdę problem.

Nie mieliśmy jeszcze żadnych negatywnych doświadczeń, ale znowu nie mieliśmy konfiguracji pod jakimkolwiek ogromnym obciążeniem. Myślę, że wszystko działałoby całkiem dobrze, ponieważ mamy dwa serwery typu slave, które replikują się z jednego serwera master, który pobiera wszystkie zapisy. Jestem całkiem pewien, że nie musimy tego robić w ten sposób, aby replikacja działała poprawnie, ale tak to skonfigurowaliśmy na początku i utknęła.

Korzystamy z CouchDB do przechowywania przychodzących i wychodzących wiadomości mobilnych oraz do raportowania tego ruchu poprzez niektóre niestandardowe widoki, które napisałem. Interfejs jest napisany w języku Python. Nie mieliśmy żadnych prawdziwych problemów technicznych i działa od końca grudnia. Jedyną przeszkodą, jaką napotkałem, było początkowo myślenie w kategoriach MapReduce, ale kiedy nauczyłem się, jak to robić, wszystko inne poszło gładko.

Obecnie używamy MongoDB w produkcji jako warstwy pamięci podręcznej, a także silnika pamięci masowej do importowania produktów i manipulowania danymi produktów. Jesteśmy firmą eCommerce zarządzającą ponad dwoma milionami produktów (ponad 100 milionów atrybutów), obejmującą ponad 10 dystrybutorów i bez MongoDB zadanie to byłoby prawie niemożliwe.

Obecnie używamy mongodb jako usługi przechowywania plików do naszej współpracy za pośrednictwem sieci LAN. Ponadto projekty takie jak Trello używają mongodb jako swojego magazynu danych backend. Korzystałem wcześniej z couchdb, ale nie ze zdolności produkcyjnych.

Używamy MongoDB do produkcji w naszej mobilnej usłudze zaplecza, mianowicie Netmera. Używamy go do przechowywania wszystkich danych użytkowników i treści.

Korzystam z CouchDB w produkcji od prawie 2 lat. Nie ma pracy migracyjnej, ponieważ projekt rozpoczął się bezpośrednio od implementacji CouchDB. Służy jako baza danych, która przechowuje dane pojedynczego produktu elektronicznego od początku do momentu pakowania.

Ponieważ sprzedajemy czujniki wymagające wysokiej dokładności, przeprowadzamy wiele testów na różnych etapach i wszystkie one zostaną zapisane w jednym dokumencie na CouchDB.

Jest pewna krzywa uczenia się, której nauczyłem się z mojego doświadczenia, która polega na pełnym wykorzystaniu widoków (lub znanych również jako widoki stałe). Widoki powinny stanowić „mały filtr” części bazy danych, która będzie często wywoływana.

Moja baza danych CouchDB nie jest tak szalona jak inna gigantyczna firma. Ale do tej pory mam się dobrze. Obecnie mam 24000 dokumentów o wielkości 700 MB.

Cechą CouchDB, którą lubię, jest „replikacja”, „przechowywanie wersji dokumentu”.

Przeczytałem wiele dobrych recenzji na MongoDB i będę chciał spróbować, jeśli będzie taka szansa.

Używamy mongodb do produkcji

www.beachfront.io - prawie 5 000 żądań zapisu na sekundę www.beachfrontbuilder.com - 500 żądań odczytu / zapisu na sekundę, utrzymanie danych 10 milionów użytkowników i olap.

Jedyne wyzwanie związane z archiwizacją danych, które pokonaliśmy, wdrażając nasz niestandardowy komponent.

To pytanie już zaakceptowało odpowiedź, ale teraz jeszcze jeden dzień NoSQL DB ma tendencję do wielu swoich wspaniałych funkcji. To jest Couchbase; który działa jak CouchbaseLitena platformie mobilnej i Couchbase Serverpo stronie serwera.

Oto niektóre z głównych cech Couchbase Lite.

Couchbase Lite to lekki, zorientowany na dokumenty (NoSQL), synchronizowany silnik bazy danych odpowiedni do osadzania w aplikacjach mobilnych.

Lekkość oznacza:

Wbudowany - silnik bazy danych to biblioteka połączona z aplikacją, a nie oddzielny proces serwera. Mały rozmiar kodu - ważny dla aplikacji mobilnych, które często są pobierane przez sieci komórkowe. Szybki czas uruchamiania - ważne, ponieważ urządzenia mobilne mają stosunkowo wolne procesory. Niskie zużycie pamięci - typowe zestawy danych mobilnych są stosunkowo małe, ale niektóre dokumenty mogą zawierać duże załączniki multimedialne. Dobra wydajność - dokładne liczby zależą oczywiście od danych i aplikacji.

Zorientowane na dokument oznacza:

Przechowuje rekordy w elastycznym formacie JSON zamiast wymagać uprzednio zdefiniowanych schematów lub normalizacji. Dokumenty mogą zawierać dowolne załączniki binarne, takie jak treści multimedialne. Format danych aplikacji może ewoluować w czasie, bez potrzeby jawnych migracji. Indeksowanie MapReduce zapewnia szybkie wyszukiwanie bez potrzeby używania specjalnych języków zapytań.

Synchronizacja oznacza:

Wszelkie dwie kopie bazy danych można zsynchronizować za pomocą wydajnego, niezawodnego, sprawdzonego algorytmu replikacji. Synchronizacja może być na żądanie lub ciągła (z opóźnieniem kilku sekund). Urządzenia mogą synchronizować się z podzbiorem dużej bazy danych na zdalnym serwerze. Mechanizm synchronizacji obsługuje przerywane i zawodne połączenia sieciowe. Konflikty można wykrywać i rozwiązywać, logika aplikacji ma pełną kontrolę nad łączeniem. Drzewa wersji pozwalają na złożone topologie replikacji, w tym między serwerami (dla wielu centrów danych) i peer-to-peer, bez utraty danych i fałszywych konfliktów. Couchbase Lite zapewnia natywne interfejsy API do bezproblemowego programowania na iOS (Objective-C) i Android (Java). Ponadto zawiera wtyczkę Couchbase Lite dla PhoneGap,

Możesz odkryć więcej na Couchbase Lite

i serwer Couchbase

To będzie następna wielka rzecz.

Mówiąc o produkcji, bezproblemowe przełączanie awaryjne / odzyskiwanie wymaga zarówno opiekunki do dziecka
1 - Couchbase, nie ma płynnego przełączania awaryjnego / odzyskiwania, wymagana jest ręczna interwencja.
ponowne równoważenie zajmuje zbyt dużo czasu, zbyt duże ryzyko w przypadku utraty więcej niż jednego węzła.

2- Mongo z odłamkami, odzyskiwanie danych z utraty serwera konfiguracji nie jest łatwym zadaniem

Adobe korzysta z MongoDB w nadchodzącej wersji Adobe Experience Manager (wcześniej Day CQ ) jako podstawowego silnika DB.

Kilku klientów w agencji, w której pracuję, korzysta z CouchDB przy projektach dla dużych klientów.

Oba są świetne i opłacalne DB, moim zdaniem. :)

Oto lista wdrożonych stron produkcyjnych z mongoDB

• The New Yorks Times : Używanie go w aplikacji do tworzenia formularzy do przesyłania zdjęć. Brak schematu Mongo daje producentom możliwość zdefiniowania dowolnej kombinacji niestandardowych pól formularza.
• SourceForge : służy do przechowywania zaplecza na stronach głównych SourceForge, stronach projektu i stronach pobierania dla wszystkich projektów.
• Bit.ly
• Etsy
• IGN : wspiera analitykę ruchu IGN w czasie rzeczywistym i interfejsy API RESTful Content.
• Justin.tv : zasila wewnętrzne narzędzia analityczne Justin.tv w zakresie wirusologii, utrzymania użytkowników i ogólnych statystyk użytkowania, których nie zapewniają gotowe rozwiązania.
• Postronny
• Intuit
• Foursquare : bazy danych Sharded Mongo są używane do większości danych w serwisie foursquare.
• Business Insider : Używanie go od początku 2008 roku. Wszystkie dane witryny, w tym posty, komentarze, a nawet obrazy, są przechowywane w MongoDB.
• Github : służy do wewnętrznej aplikacji raportującej.
• Egzaminator : migrował swoją witrynę z Cold Fusion i SQL Server do Drupal 7 i MongoDB.
• Grooveshark : obecnie używa Mongo do zarządzania ponad milionem unikalnych sesji użytkowników dziennie.
• Buzzfeed
• Dysk
• Evite : służy do analizy i szybkiego raportowania.
• Squarespace
• Shutterfly : służy do różnych wymagań dotyczących trwałego przechowywania danych w Shutterfly. MongoDB pomaga Shutterfly zbudować niezrównaną usługę, która umożliwia głębsze, bardziej osobiste relacje między klientami a osobami, które są najważniejsze w ich życiu.
• Topsy
• Udostępnij to
• Mongohq : zapewnia platformę hostingową dla MongoDB, a także wykorzystuje MongoDB jako zaplecze dla swojej usługi. Nasza strona centrów hostingowych zawiera więcej informacji o MongoHQ i innych opcjach hostingu MongoDB.

i więcej...

Wyodrębniono z: http://lineofthought.com/tools/mongodb

Możesz również sprawdzić tam inne bazy danych lub narzędzia.

MongoDB ma pewne problemy z licencjonowaniem dla firm, nie jestem pewien szczegółów, ale nasz dział prawny powiedział nam w żadnym wypadku, że nie wolno nam używać MongoDB w żadnym z naszych produktów.