Chodzi o tworzenie od podstaw ("od zera" zamiast wykorzystywać istniejące) systemów baz danych (nie ważne czy relacyjne, grafowe, wektorowe, serii czasowych etc.) "na miarę" pod klientów i ich specyficzne potrzeby.
C 
- Rejestracja:ponad 6 lat
- Ostatnio:12 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
2
wiem ze w Polsce ludzi pracuja nad bazami jak neo4j i (chyba) cassandra. Ale tworzyc baze od zera? Nie wiem czy jest w PL ktos tak bogaty. To troche jak tworzenie samochodu od zera
edytowany 1x, ostatnio: KamilAdam
Dregorio
Przez pewien czas wiem że Comarch coś takiego robił, ale okazało się niedochodowe i chyba ubili
- Rejestracja:ponad rok
- Ostatnio:ponad rok
- Postów:11
0
Nie każda customowa baza danych to bydle gabarytów tego co znamy z projektów takich jak MySQL. MySQL to system relacyjnych baz "ogólnego" zastosowania, co ma swój narzut na jego "gabaryty wagowe".
Czasem przydaje się skroić coś pod konkretne wymagania gdzie przykładowo chce się wyśrubować minimalizację czasu wyszukiwania dość prymitywnych zapytań, których cechy są dość łatwe do przewidzenia (możesz sobie tworzyć z góry struktury trzymające dane w kilku różnych porządkach i złożeniach) i w których dane wstawia się "od święta" i klienta nie obchodzi czy proces trwa 2 minuty czy 2 godziny. Tutaj przy odrobinie wprawy i wiedzy z algorytmiki czy detali dotyczących pracy CPU można prototyp przygotować w kilka godzin i go potem pieścić w detalach przez resztę czasu jaki masz na projekt plus okres wsparcia.
Oczywiście lokalizacja w Polsce firmy/grupy piszącej takie systemy nie wymusza by klient był krajowy.
- Rejestracja:około 7 lat
- Ostatnio:około 8 godzin
- Postów:857
1
Ogrom firm tak robił w przeszłości. Głównie chodzi o jakieś bazy in-memory dla odczytu, które dałoby się ogarnąć czymś open source, ale team uznał (słusznie lub nie), że napiszą własne. Kto takie rzeczy pisze? Zwykli programiści
Co do baz, gdzie ważne jest write durability to nie mam sporego doświadczenia. Zgaduję, że większość devów boi się pisać coś takiego (i słusznie)
edytowany 1x, ostatnio: slsy
- Rejestracja:ponad 6 lat
- Ostatnio:12 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
0
slsy napisał(a):
Ogrom firm tak robił w przeszłości. Głównie chodzi o jakieś bazy in-memory dla odczytu, które dałoby się ogarnąć czymś open source, ale team uznał (słusznie lub nie), że napiszą własne. Kto takie rzeczy pisze? Zwykli programiści
Czyli troche takie
- Rejestracja:około 7 lat
- Ostatnio:około 8 godzin
- Postów:857
0
KamilAdam napisał(a):
slsy napisał(a):
Ogrom firm tak robił w przeszłości. Głównie chodzi o jakieś bazy in-memory dla odczytu, które dałoby się ogarnąć czymś open source, ale team uznał (słusznie lub nie), że napiszą własne. Kto takie rzeczy pisze? Zwykli programiści
Czyli troche takie
Bardziej mi chodziło o coś trzymający stan tradycyjnie tj. nie event sourcing. To co spotkałem/o czym słyszałem:
- cache in-memory ala redis, ale trzymający dane "mądrze"
- baza w stylu widok tj. inna baza jest głównym źródłem danych a nasz projekt je obrabia do modelu i pozwala na zapytania:
- gość z pracy mówił mi o czymś napisanym w C++ co ładowało dane z Kafki i pozwalało na jakiś widok
- w bieżącej pracy mamy taką bazę in-memory, która co kilka minut zaciąga dane z bazy SQLowej i trzyma je w lekkio zmienionej formie w pamięci
- Rejestracja:prawie 20 lat
- Ostatnio:około 6 godzin
1
podobno* comarch dawno temu stworzył własną bazę danych, bo chcieli mieć funkcjonalność nasłuchiwania na zmiany (odwrotność event sourcingu?). nie wiem gdzie i czy dalej używają.
* zasłyszane, gdy pracowałem w comarchu, ale to było tak dawno, że już się nie liczy :)
edytowany 6x, ostatnio: Wibowit
w sensie chcieli mieć triggery albo coś na wzór mssql gdzie można się zasubskrybowac na query i czekać na jakieś zmiany?
triggery to raczej już były, gdy comarch powstawał. to nasłuchiwanie na zmiany to było coś czego bazy (od głównych producentów) nie oferowały. wobec tego, z tych możliwości co podałeś, ta druga jest prawdopodobna, a pierwsza nie.
- Rejestracja:ponad 8 lat
- Ostatnio:około miesiąc
- Postów:2284
0
W Polsce obecnie nie ma prawie w ogóle innowacji. Sama utrzymaniowka a Ty chcesz coś takiego. Gościu, może za granicą będziesz miał szczęście, ale wątpię aby komuś się opłacało robić coś takiego i zatrudnić emigranta zamiast lokalsa.
A czy w firmach produktowych nie tworzy się nowości?
- Rejestracja:prawie 11 lat
- Ostatnio:około 9 godzin
- Postów:1469
0
Kiedy miałem propozycje od jednej firmy jak aplikowałem na part-time. Że właśnie mają taki swój produkt już gdzieś nawet wdrożony.
chodziło o firmę Lyftron.
Lyftron jest międzynarodową firmą rozwijającą własną platformę typu “Modern Data Hub”. Stworzyliśmy własny silnik SQL, na którym oparliśmy własną platformę integracji danych. Nasze codzienne zadania to ciągła nauka i poznawanie nowych platform, z którymi możemy połączyć nasz produkt. Albo rozwiązywanie ciekawych problemów technicznych takich jak tworzenie parsera, refactoring czy też dodawanie kolejnych testów jednostkowych do 60 tysięcy już napisanych.
- Rejestracja:ponad 4 lata
- Ostatnio:około 5 godzin
- Postów:220
0
Słyszałem, że niektóre firmy z oddziałami w PL budują sobie coś na wzór Kafkowo/JVMowej 'KTable' tyle, że w językach w których jeszcze to nie istnieje lub coś im nie pasowało np. w Golang-u. Zazwyczaj są to proste wrappery z już istniejących baz 'embedded' tyle, że dubodowana jest integracja z Kafka lub innymi platformami.
Offtop: Nigdy nie zdecydowałbym się, na używanie 'tradycjnej' bazy która miała by mi zbudować jakaś firma pod moje konretne potrzeby. Zanim by to dojrzało, to by było niemało fajerwerków.
edytowany 1x, ostatnio: dmw
- Rejestracja:ponad rok
- Ostatnio:około rok
- Postów:1
0
Synerise
Codewise/VoluumDB
- Rejestracja:prawie 9 lat
- Ostatnio:3 dni
- Postów:68
1
W Katowicach dawny Mentor Graphics (obecnie Siemens) miał ekipę która razem ze Stanami rzeźbiła relacyjna bazę danych (in-house) do przechowywania projektów EDA dla kilku ich produktow. Baza była napisana w C++ i parę lat temu ekipa wciąż to utrzymywała. Odbiorcy to głównie klienci Enterpise klasy Samsung, Nexter, Ford czy ASML.
Projekt nazywał się ICDB i generalnie miał kilka innowacyjnych rozwiązań jak na lata wdrażania, ale już w 2018 roku było to dość przestarzale a liczba ludzi z wiedzą na temat internalsow kurczyła się w drastycznym tempie.
Cała siła tego rozwiązania polegała na dobrym skalowaniu przy ogromnych projektach enterprise oraz niezłej integracji/kooperacji między różnymi ich produktami.
