Znacie jakieś dobre źródła gdzie można by poczytać o MongoDB i przede wszystkim stosowaniu tej bazy w aplikacjach Railsowych? Przystępnie, tak żeby można zacząć i naklepać coś małego w Rails + MongoDB (wyłączyć Active Record)
Tak żebym zrozumiał różnicę pomiędzy MongoBD a bazami jak SQLite czy MySQL.
Jak to jest z migracjami? Wiele gemów generuje jakieś migracje, a MongoDB (w railsach korzystam z gema mongoid) podobno nie korzysta z migracji? Co teraz?
Głównie to nie rozumiem jak się mają migracje i MongoDB do siebie…
Migracji nie ma ta baza nie ma schematu, mozesz tam w kazdym rekordzie trzymac co innego. MongoID jakos to ogarnia pilnujac w miare czy pola jakie sobie zdefiniujesz tam sa. Migracje sa nie potrzeben w ogole. Mozna je stosowac/dodac jesli zmieniasz pole w bazie i chcesz by istniejace dane tez sie zmienily, ale ogolnie nie ma migracji i sa nie potrzebe. Charakter bazy jest inny i do czego innego sluzy
W bazach sql stosuje się migracje, aby dodać pola do bazy lub też przekonwertować wartości pól między polami. W NoSQL nie ma schemy (i relacji - co jest główną różnicą między bazami SQL i NoSQL) co powoduje, że nie musisz robić migracji w celu dodania pól. Jeśli chodzi o konwersje danych już istniejących w bazie, to trzeba inaczej rozwiązać, np. przez wywołanie własnego rake taska (przykład).
Ja w swojej aplikacji mam w jednym miejscu użytą metodę Queryable#ne tak że wygląda to następująco Message.ne(jakis_tam_hash) i zawsze jak na to patrze to mam wrażenie ktoś zrobił literówkę pisząc Message.new(jakis_tam_hash) Tyle razy już się na to nabrałem…
To ja Ci szybko wytłumaczę i zaoszczędzę 2 lata spapranych projektów:
Nie ma ani jednego zastosowania w którym MongoDB byłoby lepsze od PostgreSQL. Żadnego. A do tego tracisz relacyjność, Twoje dane się łatwiej rozsypią (bo schemat którego niby nie ma się zmieni w czasie życia aplikacji). Zaufaj mi, kilka ładnych aplikacji przy użyciu MongoDB zbudowałem.
Korzystając z Mongoida bardzo trudno zauważyć różnicę pomiędzy MongoDb a MySQL/Postgresql.
Dawno nie słyszałem większej bzdury. Jeśli ktoś nie widzi różnicy to nie ma pojęcia jak działa to pod spodem.
Używając MongoDB, w aplikacji gdzie Twoje dane jednak są relacyjne, bardzo szybko przekonasz się że musisz robić mapreduce, używać JavaScriptu w bazie, albo - chrońcie nas przed tym dawni bogowie - przetwarzać spore ilości danych po stronie Rubiego, bo jakoś te rekordy z sobą trzeba połączyć.
Jeśli są jakieś powody dla których chcesz użyć MongoDB, to mogą być one jedynie błędne, kilka z doświadczenia:
“Moje dane nie są z natury relacyjne.” Zazwyczaj błąd. Jeśli masz kolekcję ‘user’ i kolekcję ‘post’ albo ‘payment’ to Twoje dane są relacyjne.
“Potrzebuję robić zapytania przestrzenne.” Jest PostGIS. Jest ellasticsearch. MongoDB sobie wcale z nimi świetnie nie radzi.
“Potrzebuję zmiennej elastycznej struktury danych”. Masz JSON i hstore w postgresie.
Kilka linków wartych przejrzenia jeśli mi nadal nie ufasz:
Wybierz PostgreSQL i dobrze go skonfiguruj. Wybierz MariaDB/MySQL i dobrze je skonfiguruj. Dobry sprzęt / hosting i chwilka pracy. Zaoszczędź sobie kilku koszmarów i nie używaj MongoDB.
Ja bym powiedział, że raczej dał się ponieść hejtowi na nowe rzeczy (w tej sytuacji). Rozumiem, że nowe rzeczy trzeba poznawać, żeby nie zostać w tyle, ale trzeba do tego podchodzić z rezerwą.
Ja się do dziś jaram. Bazy NoSQL okazały się mieć swoje miejsce w stosach technologicznych wielu poważnych aplikacji – tylko że to miejsce nie jest zamiast ACID-owej bazy relacyjnej w roli głównego datastore’u.
Podobnie nodejs – jest świetny do wielu zastosowań (Ember-CLI, mądra kompilacja assetów itd.) ale nie do stawiania na tym produkcyjnej aplikacji.
Mongo to naprawdę świetna baza… ale jako uzupełnienie postgresa/mysql, nie jako główny storage danych.
Korzystam produkcyjnie z mongo w całkiem sporej aplikacji, ale wszystkie dane i tak siedzą w mysql - Mongo robi za swoisty cache z replikacją (bo replicasety są naprawdę fajnym featurem). Ale nie zaufałbym mu na tyle, żeby miał być jedyną bazą.
Myślę, że Sebanowi chodziło o to, że Mongoid stara się ukryć “nierelacyjność” Mongo (tudzież bardzo w tym pomaga). O, tutaj przykład z oficjalnej strony:
class Artist
include Mongoid::Document
field :name, type: String
embeds_many :instruments
end
class Instrument
include Mongoid::Document
field :name, type: String
embedded_in :artist
end
syd = Artist.where(name: "Syd Vicious").between(age: 18..25).first
syd.instruments.create(name: "Bass")
syd.with(database: "bands", session: "backup").save!
Jeśli ktoś nie wie jak działa baza NOSQL i próbuje bez tej wiedzy coś robić w tym kierunku, to prędzej lub później będzie jakaś katastrofa. Oby nie na produkcji
I to właściwie jest ostatecznym potwierdzeniem czemu MongoDB nie powinno być domyślnym datastore’em: bo relacje będziesz miał prędzej czy później i lepiej robić je w bazie do tego przygotowanej niż takiej, gdzie jest to na pałę robione zmapowaniem kluczy obcych i osobnym findem.
Właśnie stoję przed wyborem bazy danych do mojego prywatnego projektu, mam cichą nadzieję że przyjdzie mi się zmagać z dużą ilością danych oraz zapytań. Dlatego zamierzam już na samym początku wybrać rozwiązanie które w razie peaku nie położy projektu.
Zastanawiałem się nad mongodb oraz couchdb ze względu na replikację oraz skalowalność, ale widzę że z bazami Document Oriented jest za dużo zabawy oraz do tego konkretnego projektu się nie nadają. Z drugiej strony mamy jeszcze bazy column-family jak np. Cassandra, których struktura w projekcie railsowym wydaje się przyjaźniejsza.
Stąd moje pytanie, czy ktoś z forumowiczów używa Cassandry w produkcji i może podzielić się doświadczeniami?
Aktualnie nie masz oszacowania co do ilość danych oraz zapytań (a przynajmniej tak zakładam). Pytanie też co to jest duża ilość danych/zapytań.
Wybierasz rozwiązanie nie podpierając się żadnymi danymi ilościowymi.
To zawsze prowadzi do katastrofy pod warunkiem, że nie chodzi tylko o edukację tj. cenimy wyżej walory edukacyjne niż stabilność i niezawodność działania.
Tak w zupełności się z Tobą zgodzę, nie ukrywam że chodzi również o wartość edukacyjną. Wyczytałem ostatnio na blogu jednego z guru startupów że większość ludzi nie docenia wartości jaką niesie nauka nowych rzeczy przy tworzeniu projektu.
Tyle razy już się na to nabrałem…