Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
mstdn.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A general-purpose Mastodon server with a 500 character limit. All languages are welcome.

Administered by:

Server stats:

16K
active users

mstdn.social: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.4

#mongodb

8 posts8 participants2 posts today
Public
Habr

Как правильно выбрать базу данных для разработки: понимание моделей репликации

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных . Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​. Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​. Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации , лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

habr.com/ru/articles/895544/

ХабрКак правильно выбрать базу данных для разработки: понимание моделей репликацииВведение Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных...
#sql#nosql#mongodb
Public
FLOX Advocate

Seeking MongoDB Database Reliability Engineer and DBA

We're staffing up for our very large MongoDB environment in our datacenters and need to
fill two senior positions in the US

jobs.lever.co/rackspace/6de394

jobs.lever.co/rackspace/efb69a

Also openings for junior US support positions ( floss.social/@FLOX_advocate/11 ), India openings coming soon

#getFediHired #FediHire #FLOSSjobs #MongoDB #DBA #DBRE #WFH ( #WfHybrid in some locations ) #USjobs #Elastic

jobs.lever.coRackspace - Database Reliability Engineer (DBRE)We are seeking a skilled Database Reliability Engineer (DBRE) with expertise in MongoDB to join our team. In this role, you will be responsible for ensuring the performance, scalability, and reliability of our database infrastructure. You will work closely with development, SRE, and DevOps teams to optimize database operations, automate processes, and proactively resolve issues. Strong knowledge of MongoDB indexes, index management, integrity checks, and statistics. Understand query plans to troubleshoot performance issues. Knowledge of CRUD syntax and Aggregation Framework. Understanding of replication, vertical scaling, horizontal scaling, and DR. Expert skill in MongoDB server 6.0, 7.0 & 8.0. Advanced analytical and problem-solving skills. Strong knowledge of database automation, ideally with Python and/or Ansible. Ability to work in a team environment. Excellent communications skills; written, verbal, and presentation. Ability to apply varying leadership skills and traits that cre
Public
Pirate Praveen

FerretDB 2.0 adds support for many missing #MongoDB features required by Mailvelope Key Server. With help from @akshay I was running a patched version at keys.puri.sm

Now I can drop the patches by updating #FerretDB to 2.0. Though one feature is still missing so I have to continue using an older git snapshot that does not use this feature.

#FerretDB is a #FreeSoftware #MongoDB compatible document DB built on #PostgreSQL. MongoDB used to be Free Software, but not anymore.

keys.puri.smPurism OpenPGP Public Key ServerAn OpenPGP public key server that verifies users by sending an encrypted verification email.
Replied in thread
Public
Giacomo Tesio
@larsmb@mastodon.online

You see, when #OSI people talk about "license proliferation" they means "#copyleft proliferation" that is, in fact, the proliferation of licenses that protect the work from appropriation.

In fact, OSI approved over 100 mostly equivalent permissive licenses, among which some masterpiece like the #FairLicense https://opensource.org/license/fair just because they were backed by the right corporation.

They cry about license proliferation only when a #copyleft license conflict with the interests of their largest sponsors.

Indeed the #MongoDB #SSPL was not approved while #Amazon was one of the biggest OSI donor, while #CAL (that was even more "dangerous" as a copyleft according to the same arguments that got SSPL refused) was approved, because no #BigTech ever gave a shit about blockchain stuff (for obvious reasons).

The OSI behaviour over the years shows that they cry about license proliferation only to justify their refusals. So if they don't care, you shouldn't either.

Sure, conflicts among licenses exists (for example, you cannot mix code under the #HackingLicense and code under #GPL), but right now we need first and foremost to widen the overton windows that OSI gatekeepers try desperately to keep closed.

We have urgent need of new licenses that can protect the commons that we create without restricting their spread and evolution.

Code is Speech.

@lproven@vivaldi.net @tante@tldr.nettime.org
Open Source InitiativeFair LicenseFair License (Fair) <Copyright Information> Usage of the works is permitted provided that thisinstrument is retained with the works, so that any entitythat uses the works is notified of this…
ExploreLive feeds
About