Pliki mapowane w pamięci: plusy i minusy?

Question

Potrzebuję udostępniać dane między dwiema aplikacjami Java działającymi na tym samym komputerze (dwie różne maszyny JVM). Dokładam, że dane do udostępnienia są duże (około 7 GB). Aplikacje muszą uzyskiwać dostęp do danych bardzo szybko, ponieważ muszą odpowiadać na zapytania przychodzące z bardzo wysoką szybkością. Nie chcę, aby aplikacje przechowywały każdą kopię danych.

Widziałem, że jedną z opcji jest użycie plików mapowanych w pamięci. Aplikacja A pobiera dane skądś (powiedzmy bazę danych) i przechowuje je w plikach. Następnie aplikacja B może uzyskać dostęp do tych plików za pomocą java.nio. Nie wiem dokładnie, jak działają pliki mapowane w pamięci, wiem tylko, że dane są przechowywane w pliku i że ten plik (lub jego część) jest zmapowany do regionu pamięci (pamięci wirtualnej?). Tak więc obie aplikacje mogą odczytywać dane w pamięci, a zmiany są automatycznie (jak sądzę?) Zatwierdzone do pliku. Nie wiem również, czy istnieje maksymalny rozmiar pliku, który ma być całkowicie odwzorowany w pamięci.

Moje pierwsze pytanie brzmi: jakie są różne możliwości dla dwóch aplikacji do udostępniania danych w tym scenariuszu (tzn. Biorąc pod uwagę, że ilość danych jest bardzo duża i że dostęp do tych danych musi być bardzo szybki)? Uściślam, że to pytanie nie jest związane z I/O odwzorowanymi w pamięci, to po prostu wiedzieć, jakie są inne sposoby rozwiązania tego samego problemu.

Moje drugie pytanie brzmi: jakie są plusy i minusy używania plików mapowanych w pamięci?

Dzięki

Answer 1

Moje pierwsze pytanie, jakie są różne możliwości dwie aplikacje do udostępniania danych?

Jak S.Lott zwraca uwagę, tam dużo mechanizmów:

• OS-poziom message queues
• OS-poziom POSIX shared memory segments (ustępują po procesie śmierci)
• OS szczebla memory mappings (może być anonimowy lub z plikiem)
• OS-poziom anonymous pipes (jednokierunkowy)
• OS-poziom named pipes (jednokierunkowy)
• OS-poziom sockets (dwukierunkowy) - czy AF_UNIX lub AF_INET lub AF_INET6
• OS-poziom shared global memory - nadaje się do programów wielowątkowych
• przechowywania danych w plikach
• poziomie aplikacji message queues
• poziomie aplikacji blackboard-style tuplespaces
• poziomie aplikacji key/value stores
• poziomie aplikacji remote procedure call frameworks - many are available
• poziomie aplikacji web-based frameworks

Moje drugie pytanie jest, jakie są wady i zalety korzystania z plików pamięci odwzorowany?

Plusy:

• bardzo szybko - w zależności od tego, jak uzyskać dostęp do danych, potencjalnie zero-copy mechanizmy mogą być wykorzystane do pracy bezpośrednio na danych bez żadnych kar prędkości. Należy zachować ostrożność, aby zaktualizować obiekty w spójny sposób .
• powinien być bardzo przenośny - dostępny w systemach uniksowych prawdopodobnie przez 25 lat (dawaj lub weź), and apparently Windows has mechanisms too.

Wady:

• dzielenie jednego systemu. Jeśli chcesz rozpowszechniać swoją aplikację na wielu komputerach, pamięć współużytkowana nie jest świetną opcją. Distributed shared memory systems are available, ale czują się bardzo jak zły interfejs do mojego sposobu myślenia.
• Nawet w jednym systemie, jeśli pamięć znajduje się na pojedynczym NUMA node, ale musi być dostępna dla procesorów z wielu węzłów, żądania między-węzłowe mogą znacznie spowolnić przetwarzanie w porównaniu do nadania każdemu węzłowi własnego segmentu pamięci.
• Nie można po prostu przechowywać wskaźników - wszystkie dane muszą być przechowywane jako , aby odseparować adresy od, ponieważ pamięć może być odwzorowana w różnych miejscach w różnych procesach. Nie mam pojęcia, co to oznacza dla obiektów Java, chociaż prawdopodobnie ktoś inteligentny zrobił wszystko, aby uczynić go przezroczystym dla programistów Java. Jeśli nie korzystasz z dostarczonych mechanizmów, prawdopodobnie sam musisz wykonać pracę. (Bez rzeczywistych wskaźników w Javie, być może nie jest to bardzo uciążliwe.)
• Konsekwentna aktualizacja obiektów okazała się bardzo trudna. Przekazywanie immutable objects w systemach przekazywania komunikatów zamiast tego zwykle skutkuje programami o mniejszej liczbie błędów współbieżności. (Programowanie współbieżne w wersji Erlang jest bardzo naturalne i proste. Programowanie współbieżne w większej liczbie imperative languages ma tendencję do wprowadzania ogromnej ilości nowych kontrolek współbieżności: semaphores, mutexes, spinlocks, monitors).

Answer 2

Pliki odwzorowane w pamięci brzmią jak ból głowy. Prostą opcją i mniejszą podatnością na błędy byłoby użycie wspólnej bazy danych z pamięcią podręczną obsługującą klastry. W ten sposób zapisuje się tylko do bazy danych, a odczyty mogą być podawane z pamięci podręcznej.

Jako przykład, jak to zrobić w hibernacji zobaczyć http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-cache