sql >> Database >  >> NoSQL >> MongoDB

Maakt django met mongodb migraties tot het verleden?

Ik denk dat dit een heel goede vraag is, maar de antwoorden zullen een beetje verspreid zijn op basis van de bibliotheken die je gebruikt en je verwachtingen voor een "migratie".

Laten we eens kijken naar enkele veelvoorkomende migratieacties:

  • Voeg een veld toe: Mongo maakt dit heel gemakkelijk. Voeg gewoon een veld toe en je bent klaar.
  • Een veld verwijderen: In theorie ben je niet echt gebonden aan je schema, dus "verwijderen" is hier relatief. Als je de "property" verwijdert en het veld niet meer laadt, dan maakt het eigenlijk niet uit of dat veld in de data staat. Dus als je niet geeft om het "opschonen" van de database, dan heeft het verwijderen van een veld geen invloed op de database. Als je doe geeft om het opschonen van de DB, je zult in principe een gigantische for-lus tegen de DB moeten draaien.
  • Wijzig een veldnaam: Dit is ook een lastig probleem. Wanneer u een veld hernoemt naar "waar", hernoemt u het dan? Als je wilt dat de DB de nieuwe veldnaam weerspiegelt, dan moet je in feite een gigantische for-lus op de DB uitvoeren. Om veilig te zijn, moet u waarschijnlijk gegevens "toevoegen", dan code pushen en vervolgens het oude veld "uitschakelen".

Sommige rimpels

Het concept van een veldnaam in combinatie met een ActiveRecord-object is echter een beetje scheef. Een ActiveRecord-object biedt in feite toewijzingen van objecteigenschappen aan werkelijke databasevelden.

In een typisch RDBMS is de "grootte" van een veldnaam niet echt relevant. In Mongo neemt de veldnaam echter daadwerkelijk gegevensruimte in beslag en dit maakt een groot verschil in termen van prestaties.

Als u een vorm van "gegevensobject" zoals ActiveRecord gebruikt, waarom zou u dan proberen om volledige veldnamen in de gegevens op te slaan? De database zou waarschijnlijk alle velden in alfabetische volgorde moeten opslaan met een kaart aan de objectzijde. Dus een document zou 8 velden/eigenschappen kunnen hebben en de DB-namen zouden "a", "b"..."j" zijn, maar de objectnamen zouden leesbare dingen zijn zoals "Naam", "Prijs", "Aantal".

De reden dat ik dit ter sprake breng, is dat het nog een rimpeltje toevoegt aan Een veldnaam wijzigen . Als u een toewijzing implementeert, veroorzaakt het wijzigen van een veldnaam eigenlijk helemaal geen migratie.

Nog wat rimpels

Als je doe een migratie bij een verwijdering wilt implementeren, dan moet u dit na . doen een inzet. Je moet er ook rekening mee houden dat je geen huidige schijfruimte bespaart als je dit doet.

Mongo wijst vooraf ruimte toe en het "geeft het niet echt terug", tenzij u een DB-reparatie uitvoert. Dus als u een aantal velden op documenten verwijdert, nemen die documenten nog steeds dezelfde ruimte op de schijf in beslag. Als de documenten later worden verplaatst, kunt u ruimte terugwinnen, maar documenten worden alleen verplaatst als ze groeien.

Als u een groot veld uit veel documenten verwijdert, wilt u een reparatie uitvoeren of de nieuwe in-place compact commando.



  1. Dynamische toetsen na $groeperen op

  2. Meteor:Tracker.autorun / observeChanges &collections werken niet zoals verwacht

  3. HTML ophalen van MongoDB voor gebruik in Template

  4. MongoDB punt (.) in sleutelnaam