Автоматически заполните реализацию серверной стороны

Ответ содержится в самом сообщении об ошибке:

Error Locating Server/Instance Specified

По сути, вы указали неправильный сервер \ экземпляр в строке подключения, то есть этот бит:

Data Source=MSSQL2008-1

неправильно и не указывает на сервер, или имя сервера не разрешается в IP-адрес. Две другие возможности: (1) служба браузера SQL на компьютере с SQL Server не запущена или (2) брандмауэр Windows (или другой брандмауэр) на компьютере SQL запрещает входящие подключения.

В конечном счете, если имя сервера указано правильно, оно превращается в проблему с сетью, и вам необходимо выяснить, почему клиент не может подключиться к серверу (и это, скорее всего, будет основной проблемой сети, чем SQL Server проблема конфигурации).

21
задан 2 revs 9 June 2009 в 18:41
поделиться

9 ответов

With a set that large I would try something like a Lucene index to find the terms you want, and set a timer task that gets reset after every key stroke, with a .5 second delay. This way if a user types multiple characters fast it doesn't query the index every stroke, only when the user pauses for a second. Useability testing will let you know how long that pause should be.

Timer findQuery = new Timer();
...
public void keyStrokeDetected(..) {
   findQuery.cancel();
   findQuery = new Timer();
   String text = widget.getEnteredText();
   final TimerTask task = new TimerTask() {
      public void run() {
         ...query Lucene Index for matches
      }
   };
   findQuery.schedule(task, 350); //350 ms delay
}

Some pseduocode there, but that's the idea. Also if the query terms are set the Lucene Index can be pre-created and optimized.

6
ответ дан 29 November 2019 в 22:06
поделиться

У меня было аналогичное требование.

Я использовал реляционную базу данных с единственной хорошо проиндексированной синтетической таблицей (избегая соединений и представлений для ускорения поиска) и кеш-памятью (Ehcache) для хранения наиболее часто используемых записей.

Используя кэш MRU, вы сможете иметь мгновенное время отклика для большинства запросов, и, вероятно, нет ничего, что могло бы превзойти реляционную базу данных при доступе к индексированному столбцу в большой таблице, хранящейся на диске .

Это решение для больших наборов данных, которые вы не можете хранить на клиенте, и оно работает довольно быстро (в моем случае поиск без кеширования всегда получался менее 0,5 секунды). Он также масштабируется по горизонтали - вы всегда можете добавить дополнительные серверы и серверы баз данных.

Вы также можете поиграть с кешированием только наиболее часто используемых результатов на клиенте, особенно если вы уже реализовали это. В моем случае решение на стороне сервера достаточно быстрое, а время загрузки клиента и так достаточно медленное, так что это не оправдано.

PS Запрос клиента только тогда, когда пользователь делает паузу на определенное время, чтобы избежать повторных поисков, поскольку Предлагается хорошее решение. На моем клиенте я запрашиваю базу данных только после ввода первых трех символов, поскольку меньшее значение возвращает слишком много результатов во всех случаях.

4
ответ дан 29 November 2019 в 22:06
поделиться

Я сделал это для небольших наборов данных, используя троичное дерево поиска . Код DDJ не так уж сложно преобразовать в Java, но предполагается, что весь набор данных уместится в памяти. Существуют дисковые реализации троичных деревьев поиска ( здесь - одно в Python), но, конечно, они будут менее производительными. Однако, поскольку троичные деревья поиска превосходят частичные совпадения, производительность может быть подходящей для ваших нужд.

1
ответ дан 29 November 2019 в 22:06
поделиться

If you can't physically load all the data into RAM then you're going to have to deal with having some on disk.

What DB are you using?

For example Oracle has an option where you can keep the entire table in memory, and perform your queries against that.

MySQL also claims to have some in-memory capabilities, but I don't know much about MySQL.

You can then do away with your java based cache, or you could use the cache for the most popular/recent searches.

Obviously when you run out of RAM then some of the data will be on disk when you query for it, but depending on the load on the system, this will only be an issue for the first keypress, not the subsequent ones, as the row will be in memory after that.

If the disk seek is slowing you down, then you could investigate using SSD drives to speed up your reads.

-1
ответ дан 29 November 2019 в 22:06
поделиться

Возможно, я неправильно понял ваш вопрос, но не могли бы вы использовать плагин JQuery для Ajax информации в вашем приложении?

Я уже использовал это раньше:

Ajax Auto Suggest v2

-1
ответ дан 29 November 2019 в 22:06
поделиться

Есть ли возможные решения, которые позвольте мне масштабироваться лучше

Да, Oracle. Базы данных созданы для таких целей. Просто проиндексируйте соответствующие столбцы. Если вы сталкиваетесь со стеной решений в памяти, то компромисс со временем поиска на диске или задержкой в ​​сети, вероятно, спорный. Особенно, если вы вставите промежуточный слой кэширования.

Кроме того, вы можете уменьшить количество совпадений, если немного измените код на стороне клиента. Например, установка минимального количества символов типа перед запуском запроса или установка доли секунды задержки после того, как пользователь перестанет печатать. Если вы уже используете их, установите их немного выше.

-1
ответ дан 29 November 2019 в 22:06
поделиться

В итоге я решил эту проблему с помощью Lucene; начальные тесты производительности кажутся достаточными для нашего случая использования. Чтобы заставить префиксные запросы работать, потребовался небольшой взлом, так как я столкнулся с исключением TooManyClauses при расширении запросов, таких как «Jeff At *». Я закончил тем, что обернул свой IndexReader с помощью FilterIndexReader и установил жесткое ограничение на количество терминов, возвращаемых при вызове префиксного термина. Вот мой код:

Directory directory = FSDirectory.getDirectory(indexDir);
IndexReader reader = IndexReader.open(directory);
FilterIndexReader filteredReader = new FilterIndexReader(reader) {
  @Override public TermEnum terms(Term t) throws IOException {
    final TermEnum origEnum = super.terms(t);

    return new TermEnum() {
      protected int count = 0;
      @Override public boolean next() throws IOException {
        if (count++ < (BooleanQuery.getMaxClauseCount() - 10))
          return origEnum.next();
        else return false;
      }

      @Override public Term term() {
        return origEnum.term();
      }

      @Override public int docFreq() {
        return origEnum.docFreq();
      }

      @Override public void close() throws IOException {
        origEnum.close();
      }
    };
  }
};

IndexSearcher searcher = new IndexSearcher(filteredReader);
2
ответ дан 29 November 2019 в 22:06
поделиться

Для тех, кто наткнулся на этот вопрос...

Я только что опубликовал на стороне сервера автозавершение реализации на Google Code. Проект включает в себя java библиотеку, которая может быть интегрирована в существующие приложения, и автономный сервер автозавершения HTTP AJAX.

Я надеюсь, что это позволит людям интегрировать эффективное автозавершение в свои приложения. Бейте по шинам!

3
ответ дан 29 November 2019 в 22:06
поделиться

Я использовал хеш-таблицу и mmap () И список терминов из 10 000 000+ записей не проблема. См. Демонстрацию здесь: http://olegh.ath.cx/autocomplete.html

1
ответ дан 29 November 2019 в 22:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: