Sign In
Create Account
Back to top
 |
Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. www.neurohope.ro |
Subarbori multipli – metode mai eficiente de stocare?
Last Updated: Jun 09 2017 13:15, Started by
dani.user
, Jun 07 2017 21:50
·
0
0
#1
Posted 07 June 2017 - 21:50
|
Fie un arbore binar (balansat) ce contine multe (sute de mii de) elemente in memorie (pointeri la structuri mai complexe), sortate dupa un anumit criteriu.
O parte din acele elemente am nevoie sa le pot cauta (si itera in ordine crescatoare prin ele) in seturi mai mici. As putea crea un nou arbore, independent de primul, care sa contina, de exemplu, doar 50 din elementele primului, sortate in aceeasi ordine. Operatii de modificare a arborilor pot avea loc, acestia nefiind constanti pe termen lung. Exista vreo metoda mai rapida/putin consumatoare de memorie decat sa pastrez arborele mare + n arbori mici independenti (fiecare cu doar un subset din elementele celui mare, nici un element in plus)? Edited by dani.user, 07 June 2017 - 21:53. |
#2
Posted 07 June 2017 - 22:18
|
Foarte abstracta descrierea problemei, nu am inteles cu exactitate ce cauti.
Dar problema suna de ca si cum ai face lucruri ca o baza de date. Deci RB-Tree sau similar? O nota aditionala, acum cateva zile citeam un Edited by OriginalCopy, 07 June 2017 - 22:21. |
#3
Posted 08 June 2017 - 06:28
|
Nu cred ca ai dat suficiente amanunte,dar daca in arborele mare sunt deja ordonate cum vrei tu, poti sa tii doar n multiple puncte de intrare in arborele mare fara sa mai creezi cei n arbori independenti.
|
#4
Posted 08 June 2017 - 06:54
|
Un exemplu mai concret: Intr-un RB-Tree am (pointeri spre) toate articolele, ordonate dupa nume. So far, so good.
Dar, vreau sa pot itera usor si doar prin articolele scrise de un anumit user. In prezent, entitatiile userilor contin cate un alt RB-Tree avand doar un subset din articolele initiale (doar cele scrise de userul in cauza), ordonate la fel. Intrebarea: As putea retine mai eficient subsetul de articole al fiecarui user, fara sa scada (seminificativ) performanta la editare/cautare/iterare in ordine? Nu ma limiteaza solutia curenta, doar incerc sa ma gandesc la solutii alternative Edited by dani.user, 08 June 2017 - 06:55. |
#5
Posted 08 June 2017 - 08:03
|
Arborii in general sunt un bun compromis la editare/cautare/iterare, deci as zice ca solutia aleasa e greu de imbunatatit fara sa speculezi ceva specific in setul tau de date.
|
#7
Posted 08 June 2017 - 10:05
|
Întotdeauna vei avea de ales între a consuma mai multă memorie și a avea datele la îndemână, sau a consuma mai puțină memorie și a trebui să parcurgi un set mai mare de date.
Nu am mai lucrat de ceva vreme cu arbori, dar un arbore binar balansat era in O(log(n)) ca timp de căutare, ceea ce e mai puțin decât un O(n) pentru o parcurgere clasică. Ah, căutare după alte criterii decât cel după care a fost sortat arborele. Well, înafară de a construi un nou arbore după criteriul dat, no idea. De obicei responsabilitatea aranjării datelor e delegată bazei de date. Edited by RedDev, 08 June 2017 - 10:09. |
#8
Posted 08 June 2017 - 16:33
|
Un exemplu mai concret: Intr-un RB-Tree am (pointeri spre) toate articolele, ordonate dupa nume. So far, so good. Dar, vreau sa pot itera usor si doar prin articolele scrise de un anumit user. In prezent, entitatiile userilor contin cate un alt RB-Tree avand doar un subset din articolele initiale (doar cele scrise de userul in cauza), ordonate la fel. Intrebarea: As putea retine mai eficient subsetul de articole al fiecarui user, fara sa scada (seminificativ) performanta la editare/cautare/iterare in ordine? Nu ma limiteaza solutia curenta, doar incerc sa ma gandesc la solutii alternative daca am inteles bine: prin subsetul de articole inseamna ca ai copiat articolele in alt mini-arbore sa le poti accesa repede? daca da, ai toate articolele de doua ori stocate. Alternativa ar fi sa pastrezi pointerii catre articole in mini arbori, dar enuntul e putin cam sumar, poate nu pricepem complet. la hash-maps te-ai gandit? cu o distribuire eficienta accesul amortizat parca e o(1). |
#9
Posted 09 June 2017 - 08:17
#10
Posted 09 June 2017 - 09:49
|
toti am merge, dar asta e un subiect interminabil. nu am vazut inca O singura aplicatie/sistem stabil dpdv multithreading.
|
|
#11
Posted 09 June 2017 - 10:46
|
nu am vazut inca O singura aplicatie/sistem stabil dpdv multithreading. |
#12
Posted 09 June 2017 - 11:04
|
Hashmap nu ma ajuta. E mai rapida la cautari, dar cand caut ceva, vreau adesea sa iau si urmatoarele n elemente (in ordinea sortarii).
Aplicatia din semnatura e stabila/gandita pentru multithreading. Partea de retelistica/http e paralelizata "cat se poate", iar partea de date e protejata de un multi-reader/single-writer lock. Cat timp doar se citesc date, cate core-uri atatea cereri procesate in paralel. |
#13
Posted 09 June 2017 - 12:11
|
Multi reader single writer funcționează perfect pentru aplicații unde write nu e atât de intensiv, adică majoritatea aplicațiilor.
Iar dacă vrei la un moment dat să îl faci distribuit, trebuie să coordonezi doar writers. Cât despre problemă, definește-o mai bine, altfel alergi după fata morgana. |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
-
- Change Theme
- English
- Mark Community Read
- Termene & conditii
- Confidentialitate
- Consimtamant
- Cookies
- Help
© 2001-2024 Softpedia. All rights reserved. Softpedia® and the Softpedia logo are registered trademarks of SoftNews Net SRL.
Ora implicita a Forumului Softpedia este ora standard a Romaniei (GMT+2). Mai multe informatii →
⚠ Postarile afisate pe Forumul Softpedia reprezinta o opinie subiectiva a membrilor care le-au publicat si nu a SoftNews Net SRL.